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FOREWORD 

This  second  volume  of  the  Final  Technical  Report  summarizes,  task-by-task,  the  technical 
efforts  performed  imder  Air  Force  Contract  F33615-85-C-5122,  Geometric  Modeling  Applica¬ 
tions  Interface  Program  (GMAP),  covering  the  period  1  August  1985  to  31  March  1989.  The 
contract  was  ^Mnsored  by  the  Manufacturing  Technology  Directorate,  Wright  Research  & 
Development  Center,  Air  Force  Systems  Command,  Wright-Patterson  Air  Force  Base,  Ohio, 
45433-6533.  This  program  was  administered  under  the  technical  direction  of  Mr.  Charles 
Gilman. 

The  primary  contractor  was  Pratt  &  Whitney,  an  operating  unit  of  United  Technologies 
Corporation  (UTC).  Pratt  &  Whitney  engaged  several  additional  firms  as  subcontractors 
including  the  United  Technologies  Research  Center  (UTRC),  McDoxmell  Aircraft  Company 
(MCAIR),  and  International  TechneGroup  Incorporated  (FTI)  to  assist  in  various  tasks  of  the 
program.  At  Pratt  &  Whitney,  the  program  was  managed  by  Mr.  Richard  Lopatka.  Ms.  Linda 
Phillips  was  the  Program  Integrator,  and  Mr.  John  Hamill  was  the  Deputy  Program  Manager. 

Note:  The  number  and  date  in  the  upper  right  comer  of  each  page  of  this  document  indicate 
that  the  volume  has  been  prepared  according  to  the  ICAM  CM  Life  Cycle  Documentation 
requirements  for  a  Configuration  Item  (Cl). 
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SECTION  1 
INTRODUCTION 


1.1  PROJECT  OBJECTIVES 

The  Geometric  Modeling  Applications  Interface  Program  (GMAP)  had  two  primary 
objectives:  (1)  identify  and  organize  the  geometric  and  nonshape  data  needed  for  the  engineering, 
manufacturing,  and  logistics  support  of  complex  structured  components  and  (2)  demonstrate  the 
communication  and  manipulation  of  these  data  for  jet  engine  turbine  blades  and  disks.  It  was 
anticipated  that  attainment  of  these  objectives  would  improve  communication  between  aerospace 
prime  contractors  and  their  partners,  subcontractors,  and  customers. 

The  program  expanded  upon  the  results  obtained  in  the  Product  DeHnition  Data  Interface 
(PDDI),  Project  5601  (Contract  F33615-82-C-5036),  which  established  a  mechanism  for 
communicating  throughout  manufacturing,  complete  part  descriptions  as  received  from  engineer¬ 
ing.  Identifying  the  classes  of  information  to  be  included  in  the  PDDI  definition  constituted  a 
large  part  of  the  PDDI  project.  Establishing  a  communication  format  to  exchange  this  part 
definition  constituted  the  remainder. 

The  requirement  for  GMAP  stemed  from  the  increasing  use  of  geometric  modeler-based 
software  systems  in  aerospace  product  life  cycle  operations  and  the  need  to  share  information 
produced  by  these  systems  in  an  efficient  and  cost-effective  manner.  Geometric  modeling  is  a 
fundamental  building  block  of  the  many  computer  automated  design,  analysis,  manufacturing, 
inspection,  and  product  support  systems  that  have  evolved  to  date.  In  the  current  environment  of 
rapidly  evolving  computer  systems  with  differing  capabilities,  there  is  no  single  commercial  or 
homegrown  software  system  which  can  satisfy  the  needs  of  all  applications.  Therefore,  the  need 
to  integrate  systems  so  that  the  data  they  produce  and  manipulate  can  be  shared  is  an  important 
requirement  that  must  be  developed. 

1.2  PROJECT  SCOPE 

Five  technical  tasks  were  employed  in  GMAP  to  fulfill  its  objectives.  They  are  described  in 
the  following  paragraphs. 

Task  1,  UNDERSTAND  THE  PROBLEM,  consisted  of  three  subtasks: 

1.1  Establish  the  Management  Planning,  Project  Schedule,  and  Scope; 

1.2  Identify  the  GMAP  Needs; 

1.3  Define  the  System  Requirements. 

Subtask  1.1  was  a  comprehensive  subtask  encompassing  the  establishment  of:  an  Industry 
Review  Board,  Product  Assurance/Quality  Assurance  plans,  and  coordination  with  other 
(Computer  Integrated  Manufacturing  projects;  selecting  a  part  family  for  study,  and  performing  a 
high  level  functional  analysis  of  the  applications  involved  in  the  life  cycle  of  the  selected  part 
family. 

Subtask  1.2  included  determining  GMAP  appbcation  interface  needs  using  a  “walk¬ 
through”  of  a  product’s  life  cycle.  Subtask  1.3  established  the  to-be  system  requirements  from  the 
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SECTION  2 

EXECUTIVE  SUMMARY 

2.1  TASK  1  —  UNDERSTAND  THE  PROBLEM 

•  The  organization:  assignment  of  functions,  duties,  and  responsibilities; 
management  procedures  and  policies;  and  reporting  procedures  were  estab¬ 
lished  and  documented  early  in  the  program.  The  Pratt  &  Whitney  GMAP 
Program  Office  was  managed  by  a  Program  Manager,  a  Deputy  Program 
Manager,  and  a  third  member.  Program  Integrator,  to  unify  efforts  and  to  aid 
in  the  transfer  of  technology. 

•  Pratt  &  Whitney  utilized  three  subcontractors  to  assist  on  various  tasks  of  the 
original  GMAP:  McDonnell  Aircraft  Company  (MCAIR),  International 
TechneGroup  Inc.  (ITI),  and  United  Technologies  Research  Center  (UTRC). 
Other  companies  were  involved  during  various  GMAP  system  demonstra¬ 
tions. 

•  The  Program  Management  Office  established  Project  Master  Schedules  that 
both  Pratt  &  Whitney  and  program  subcontractors  agreed  to  follow. 

•  After  Task  responsibilities  were  assigned,  the  GMAP  participants  used  the 
IDEFO  function  modeling  methodology  to  describe  Pratt  &  Whitney’s  design 
and  manufacturing  facilities  for  jet  engine  turbine  blades. 

•  An  upper  level  GMAP  scoping  function  model  was  created  to  help  provide  an 
understanding  of  the  role  GMAP  will  have  in  the  product  life  cycle  of  turbine 
blades,  disks  and  assemblies. 

•  A  family  of  jet  engine  turbine  blades  and  disks  was  selected  for  the  detailed 
walkthroughs  of  the  life  cycle  activities  associated  with  the  design,  manufac¬ 
ture,  and  support  of  these  parts. 

•  Candidate  functional  applications  for  demonstration  of  GMAP  technology 
were  identified  after  applying  IDEFO  modeling  techniques  during  the  detailed 
functional  modeling  walkthroughs. 

•  Three  walkthrough  teams  were  set  up,  combining  the  related  functions  of 
Design  with  Analysis;  Manufacturing  with  Inspection;  and  Product  Support 
with  Logistics  Support. 

•  Approximately  100  functional  applications  were  identified  with  the  IDEFO 
function  model,  many  of  which  were  supported  by  computer  programs, 
including:  graphic  systeaa,  g^metry  processors,  N/C  toolpath  utilities, 
cooling  hole  laser  drilling  programs,  coordinate  measuring  machine  program 
generators,  finite  element  stress  programs,  and  tolerance  chart  programs. 
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identified  needs,  and  completed  a  State-of-the-Art  Survey  of  existing  capabilities  that  identified 
both  the  minimum,  and  the  functional,  requirements  of  a  product  modeler. 

Task  2,  ESTABLISH  THE  PRELIMINARY  AND  DETAILED  DESIGN,  consisted  of 
four  subtasks: 

2.1  Establish  Preliminary  Design, 

2.2  Review  Preliminary  Design, 

2.3  Establish  Detail  Design, 

2.4  Perform  Critical  Design  Review. 

In  Subtask  2.1,  a  conceptual  design  for  GMAP  was  developed,  including  identification  of 
required  enhancements  to  PDDI  technology  and  a  plan  for  testing  the  GMAP  system  software. 
In  subtask  2.2,  this  work  was  reviewed  to  ensure  that  the  design  met  all  of  the  system 
requiremr  its  established  in  Task  1.  Subtask  2.3  detailed  the  design,  and  established  plans  for 
testing  loi''stic  application  interfaces.  Subtask  2.4  ensured  review  of  the  detail  design. 

Task  3, :  TEGRATE  EXISTING  FUNCTIONAL  APPLICATIONS,  consisted  of  design¬ 
ing  interfaces  fo.  ivo  existing  functional  applications,  the  Retirement  for  Cause  disk  inspection 
system  and  the  Integrated  Blade  Inspection  S3rstem,  at  the  Air  Force’s  San  Antonio- Air  Logistics 
Center. 

In  Task  4,  BUILD  AND  INTEGRATE  THE  APPLICATION  INTERFACE,  GMAP 
software  was  constructed  and  the  function,  performance,  and  integration  of  the  system  was 
verified  in  accordance  with  the  design  and  test  plans  established  in  Tasks  2  and  3.  Appbcable 
manuals  were  produced  for  the  installation  and  operation  of  the  system. 

Task  5,  IMPLEMENT,  MAINTAIN,  AND  DEMONSTRATE  GMAP,  included  four 
Subtasks: 

5.1  Implement  GMAP, 

5.2  Maintain  GMAP, 

5.3  Project  Performance  and  Benefits  Analysis, 

5.4  Demonstrate  GMAP. 

Subtask  5.1  demonstrated  the  effectiveness  of  the  GMAP  system  by  implementing  it  on 
contractor,  customer  and  outside  supplier  computer  systems.  Subtask  5.2  provided  modifications 
to  the  GMAP  system  during  testing  as  required.  Subtask  5.3  identified  the  potential  benefits  if 
GMAP  was  fully  implemented  on  life  cycle  applications.  Under  Subtask  5.4,  several  videotapes 
were  produced  to  demonstrate  the  GMAP  system  performance. 

In  addition.  Task  6,  DELIVERABLE  REPORTS,  was  included  as  part  of  GMAP  to 
account  for  documentation.  A  variety  of  technical  and  financial  reports  were  produced  in 
accordance  with  the  Omtract  Data  Requirements  List  (DD  Form  1423)  and  the  Integrated 
Computer  Aided  Manufacturing  Life  Cycle  Documentation  Schedule.  The  msgority  of  these 
documents  are  discussed  in  connection  with  the  technical  efforts  that  they  support. 
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•  The  design  and  analysis  walkthrough  took  place  at  the  Pratt  &  Whitney 
facilities  in  West  Palm  Beach,  Florida.  It  involved  a  total  of  17  interviews 
with  29  experts  from  various  discipline  areas. 

In  design  and  analysis,  the  amount  of  computerization  and  electronic 
interface  ranged  from  complete  to  partial.  This  area  created  the  Product 
Definition  Data  (PDD)  that  is  carried  in  both  electronic  and  paper  forms.  The 
walkthrough  also  showed  that  several  specific  design  and  analysis  disciplines 
worked  together  to  produce  a  final  part  design. 

•  Identification  of  manufacturing  and  inspection  candidate  functional  applica¬ 
tions  also  occurred  with  the  IDEFO  analysis  described  previously.  The 
manufacturing  and  inspection  walkthroughs  were  conducted  at  five  different 
facilities  throughout  Connecticut  and  in  Georgia. 

Manufacturing  was  broken  into  six  major  functions  that  were  investigated  to 
identify  and  track  the  use  of  PDD.  Manufacturing  functions  were  decentral¬ 
ized  and  highly  dispersed.  This  pointed  out  a  benefit  to  using  electronic  PDD. 
Suppliers  were  highly  involved  in  the  manufacturing  process.  Production 
planning  was  the  key  function  in  the  development  and  use  of  PDD.  All  other 
functions  relied  on  production  planning  as  their  primary  source  of  technical 
information  and  analysis. 

•  Product  Support  consisted  of  all  support  activities  necessary  to  service 
customers  that  purchased  Pratt  &  Whitney  engines.  It  provided  technical 
information  and  instructions,  processed  warranty  claims,  provided  pricing 
information,  processed  orders  for  spare  parts,  established  logistic  require¬ 
ments,  and  forecast  future  parts  needs. 

•  Two  specific  areas  within  logistics  support  dealing  with  inspection  processes 
were  studied.  One  dealt  with  blades,  the  Integrated  Blade  Inspection  System 
(IBIS);  the  other  with  disks.  Retirement  for  Cause  (RFC).  Logistics  support 
involved  the  disassembly,  inspection,  service,  repair,  and  reassembly  of  in- 
service  aerospace  products. 

IBIS  provided  an  automated  blade  inspection  capability  for  the  logistics 
support  facility.  Three  inspection  submodules  performed  the  actual  inspec¬ 
tion:  the  Fluorescent  Penetrant  Inspection  Module,  the  Infrared  Inspection 
Module,  and  the  X-Ray  Inspection  Module. 

The  RFC  system  was  an  automated,  robotics-based  inspection  system 
developed  by  Systems  Research  Laboratories,  Inc  in  Dayton,  Ohio,  for  the 
San  Antonio  Air  Logistics  Center  (SA-ALC).  It  was  used  to  detect  engine  disk 
surface  and  internal  flaws  using  eddy  current  and  ultrasonic  nondestructive 
evaluation  techniques. 

•  Pratt  &  Whitney  investigated  other  Air  Force  Materials  Lab  CIM  Branch 
programs  as  well  as  industry  efforts  to  establish  technology  transfer 
opportiinities. 
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•  An  Industry  Review  Board  (IRB)  was  established  to  review  the  progress  of 
GMAP;  assess  the  technical  direction  of  the  project;  offer  advice  from  a  broad 
base  of  industrial  background  and  experience;  and  provide  an  important 
vehicle  to  assist  with  the  transfer  of  GMAP  technology  to  industry  in  general. 
Mr.  G.  Hess,  Vice  President  —  Systems  and  Planning  for  Ingersoll  Milling 
Machine  Company,  agreed  to  be  the  Chairman  of  the  IRB.  Mr.  J.  Lemon, 
President  of  International  TechneGroup,  Inc.,  agreed  to  be  Secretary  of  the 
IRB. 

There  were  six  IRB  meetings.  Each  meeting  reviewed  the  technical  progress 
of  the  program  and  provided  a  forum  for  technical  guidance. 

•  Pratt  &  Whitney  prepared  a  Software  Quality  Assurance  Plan  to  ensure  that 
computer  software  developed  during  the  program  conforms  to  quality 
requirements  in  a  cost-effective  maimer.  The  Plan  applied  tc  all  program 
software  deliverable  to  the  Air  Force. 

2.2  TASK  2  —  ESTABLISH  THE  PREUMINARY  AND  DETAILED  DESIGN 

•  Approximately  100  candidate  functional  applications  were  identified  for 
IDEFIX  methodology  information  modeling.  Sixteen  key  functional  applica¬ 
tion  areas  were  selected  from  the  100  for  evaluation  of  information,  or  data, 
needs. 

•  The  PDD  needs  for  each  of  the  16  applications  were  converted  into  specific 
types  of  data  that  would  be  needed  across  a  broad  spectrum  of  industry.  This 
resulted  in  seven  classes  of  data:  Geometry,  Topology,  Form  Features,  Shape, 
Tolerances,  Nonshape  and  Notes,  and  Administrative  and  Assembly. 

Key  findings  relating  to  these  needs  were: 

For  complex  mechanical  components,  PDD  must  include  all 
concepts,  attributes,  and  relationships  normally  communicated 
from  design  throughout  the  product  life  cycle.  The  engineering 
drawing  and  related  technical  documents  have  been  the  vehicles 
historically  used  for  this  purpose.  For  complex  mechanical 
components,  both  shape  and  nonshape  information  and  process 
requirements  are  needed  to  represent  fully  a  component  or 
assembly. 

Applications  that  are  users  of  PDD,  as  opposed  to  those  that  are 
producers  of  PDD,  are  the  primary  beneficiaries  of  an  electronic 
equivalent  of  the  engineering  drawing. 

Computer-sensible  product  data  are  needed  for  applications  to 
become  more  automated.  This  is  esp>ecially  true  for  most 
applications  studied  in  manufacturing,  inspection,  and  logistics 
support. 
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The  primi^ry  responsibility  for  creating  PDD  lies  within  the 
traditional  mechanical  design  and  drafting  functions. 

Modelers  need  to  be  developed  to  create  the  required  PDD. 
These  modelers  may  actually  be  a  system  of  modelers  capable  of 
providing  the  various  shape  and  nonshape  data  required.  For 
shape  data,  existing  geometric  and  solid  modelers  are  capable  of 
producing  the  geometry  and  topology  definitions  required  by 
some  using  applications,  but  not  without  problems  and  limita¬ 
tions. 

“In-process  geometry”  must  be  derivable  and  representable  from 
PDD  for  Process  Planning,  N/C  Machining,  Automated  Inspec¬ 
tion,  and  Tool  Design  ^plications. 

There  is  a  need  to  preserve  the  constructive  origins  of  shape 
PDD  for  some  applications. 

Although  solid  model  representation  of  shap>e  is  required  for 
certain  automated  applications,  not  all  applications  require  such 
complete  information.  Some  applications  only  require  2-D 
geometry.  Examples  are  applications  dealing  with  Body  of 
Revolution  (BOR)  or  turned  parts,  and  flat  sheet-like  parts. 

There  is  a  need  to  represent  geometry  in  multiple  forms 
depending  upon  the  using  application.  This  leads  to  the 
requirement  for  standardized  representations.  Evaluator  utilities 
capable  of  converting  between  standard  forms  would  be  very 
useful. 

Features  are  a  key  to  applications  such  as  automated  process 
planning,  since  features  are  the  result  of  individual  processes. 

Tolerances,  datums,  and  their  relationships  to  part  shape  are 
fundamental  to  future  automated  applications.  Representations 
of  tolerances  and  datums  must  parallel  traditional  industry 
standards  for  reasons  of  acceptability,  useability,  traditional 
practice,  and  so  on. 

Process  requirements  normally  conveyed  to  manufacturing  and 
inq>ection  via  notes  and  specification  invocation  on  engineering 
drawings  must  continue  to  be  conveyed  in  the  electronic  PDD 
form.  The  bulk  of  this  information  needs  to  be  represented  in  a 
computer-sensible  form.  Other  information  is  only  human 
understandable  and  needs  to  be  conveyed  via  note  text  in  the 
PDD  model. 

Information  is  communicated  from  engineering  and  product 
support  to  logistics  support  by  using  the  technicac  order.  This 
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information  is  analogous  in  form  to  the  process  requirements 
communicated  from  engineering  to  manufacturing.  Provisions 
for  incorporating  these  data  in  the  full  PDD  model  are  essential. 

Administrative  information  pertaining  to  the  control  and  man¬ 
agement  of  the  PDD  needs  to  be  included  with  the  technical 
PDD. 

Assembly  PDD  is  normally  conveyed  using  layout  and  assembly 
drawings.  Information  contained  on  these  traditional  documents 
falls  into  categories  similar  to  those  required  for  component 
PDD.  These  are  geometry,  topology,  features,  tolerances,  non¬ 
shape  and  notes  (process  requirements  being  assembly  require¬ 
ments  in  this  case),  and  administrative. 

•  PDD  requirements  of  the  GMAP  system  were  synthesized  from  the  results  of 
the  needs  analysis  and  presented  in  the  form  of  entities. 

•  The  minimum  requirements  of  a  product  modeler  were  established.  Such  a 
modeler  is  required  to  take  advantage  of  the  complete  PDD  capabilities 
provided  by  GMAP. 

•  Pratt  &  Whitney  contracted  D.  Appleton  Company  (DACOM)  to  produce  a 
follow-on  document  entitled  “Functional  Requirements  of  a  Product  Mode¬ 
ler.” 

•  A  survey  was  conducted  to  identify  current  and  emerging  technologies  that 
impact  the  content,  usage,  exchange,  and  management  of  PDD  models.  This 
survey  also  identified  technology  voids  by  correlating  the  prioritized  needs 
from  the  GMAP  Needs  Analysis  Document  with  the  survey  findings.  It  was 
found  that  completely  integrated  product  modelers  were  not  yet  available. 

•  To  establish  a  preliminary  design,  IDEFIX  information  modeling  was 
performed  for  each  data  class.  In  the  process,  a  new  data  class,  the  “Shape” 
data  class  was  added  to  the  GMAP  schema.  The  concepts  provided  by  the 
Shape  data  class  helped  accelerate  the  work  of  the  PDES  community. 

•  The  System  Test  Plan  provided  a  strategy  for  testing  and  validating  the 
elements  and  functionality  of  GMAP  as  defined  in  the  System  Design 
Specification. 

•  Enhancements  or  additions  to  the  PDDI  software  were  identified  in  four 
areas:  PDD  model  access.  Schema  Manager,  PDD  Editor,  and  System 
Translator  performance  improvements. 

The  Name/Value  Interface  (N/VI)  enhancement  to  PDD  model  access  Creed 
application  programs  from  the  need  to  be  concerned  with  the  physical 
location  of  attribute  values  within  an  entity  in  the  working  form  of  the 
product  model. 
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The  Schema  Manager  was  necessary  to  create  entity  definitions.  The  Schema 
Manager  would  improve  the  flexibility  of  the  software  for  both  growth  and 
development. 

The  PDD  Editor  was  designed  to  populate  PDD  models  with  entities  as 
deSned  in  the  schema.  It  could  also  create,  modify,  delete,  and  view  the  PDD 
contained  in  the  working  form  model 

The  System  Translator  is  a  software  mechanism  developed  under  PDDI  for 
passing  data  between  dissimilar  systems.  Enhancements  were  also  imple¬ 
mented  to  make  the  System  Translator  conform  to  the  PDES  exchange 
format.  Several  enhancements  were  made  that  reduced  the  CPU  time  for 
System  Translator  operation. 

•  fteview  of  the  progress  and  the  technical  adequacy  of  the  GMAP  system 
■'esign  was  conducted  as  part  of  the  the  third  IRB  meeting  during  April  1987. 

•  Thi.  GMAP  System  Component  As-designed  Product  Specification 
(Cl  1.  *6024(X)31U)  established  the  design  of  the  GMAP  System  Compo¬ 
nents. 

•  Because  of  the  close  coordination  with  the  Air  Force  and  the  IRB  in 
establishing  the  detail  design,  no  formal  critical  design  review  was  performed. 

2.3  TASK  3  —  INTEGRATE  EXISTING  FUNCTIONAL  APPUCATIONS 

•  The  GMAP-to-RFC  Interface  was  designed  (1)  to  translate  the  GMAP  disk 
model  PDD  from  exchange  format  to  working  form  in  VAX  computer 
memory  and  (2)  to  translate  the  model  in  working  form  to  the  Unigraphics 
data  base  that  is  resident  on  the  RFC  sj'stem  at  System  Research  Laborato¬ 
ries. 

•  The  GMAP-to-IBIS  Interface  was  designed  to  (1)  derive  an  IBIS-compatible, 
bi-cubic  patch  surface  representation  of  the  blade  from  the  Non-Uniform 
Rational  B-spline  (NURB)  surface  representation  contained  in  the  GMAP 
model  and  (2)  extract  the  flaw  criteria  and  inspection  zone  information  from 
the  GMAP  model  and  make  them  available  to  the  Inspection  Plan  (Seneration 
Subsystem  of  IBIS. 

•  RFC  and  IBIS  Unit  Test  Plans  were  developed  to  assure  that  each 
requirement  stated  in  the  respective  Development  Specification  would  be 
adequately  validated,  and  that  the  data  generated  during  demonstrations 
would  verify  that  the  performance  objectives  were  met. 

2.4  TASK  4  —  BUILD  AND  INTEGRATE  APPUCATIONS  INTERFACE 

•  The  software  that  comprises  the  GMAP  system  and  which  was  delivered  to 
the  Air  Force  includes  eight  components. 
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System  Translator  —  A  software  mechanism  used  for  passing  data  between 
dissimilar  systems  initially  developed  under  PDDl  and  enhanced  in  GMAP. 

The  Model  Access  Software  with  N/VI  —  The  Model  Access  Software  is  a  set 
of  routines  that  allow  access  to  product  models  for  creation,  modification, 
deletion,  and  navigation  at  the  entity  level.  The  N/VI  is  a  set  of  PASCAL 
subroutines  that  help  query  the  PDD  model  about  entity  attributes.  It  helps 
avoid  altering  an  application  program  when  certain  elements  of  that 
program’s  PDD  model  are  changed  by  freeing  the  application  programs  from 
the  need  to  know  the  physical  location  of  an  attribute  for  an  entity.  It 
provides  access  at  the  attribute  level. 

Schema  Manager  —  One  of  two  new  components  developed  in  GMAP,  it 
creates  the  Data  Dictionary  and  PASCAL  include  files  and  manages  the 
schema.  The  Data  Dictionary  and  PASCAL  include  files  are  the  physical  files 
that  define  the  data  schema  to  the  system  components  and  applications. 

PDD  Editor  —  The  second  of  two  new  components  developed  in  GMAP,  it 
adds  PDD  such  as  tolerances,  form  features,  administrative  and  assembly 
data,  etc.  to  demonstration  models  for  each  application  from  Data  Dictionary 
definitions. 

Data  Dictionary  —  A  listing  of  all  the  possible  entity  definitions  that  could 
occur  in  any  model  including  their  names,  data  types,  size,  displacement  and 
usage.  It  is  used  primarily  in  FORTRAN  programs. 

PASCAL  Include  Files  —  Representations  of  the  Data  Dictionary  for  use  in 
PASCAL  application  programs. 

Interfaces  to  the  Air  Force’s  RFC  and  IBIS  at  the  San  Antonio  Air  Logistics 
Center. 

•  Commercial  modeling  systems  in  use  at  Pratt  &  Whitney  were  used  for  the 
initial  geometry  and  topology  creation  of  the  GMAP  PDD  models  for  testing. 
These  systems  included  the  Computer  Aided  Engineering  Design  System 
(CAEDS),  Computervision’s  CADDS4X  system,  and  Manufacturing  Consul¬ 
tant  Services’  ANVIL  4000  system.  Ad^tional  PDD,  such  as  tolerances, 
nonshape,  form  features,  and  so  on  were  added  by  the  PDD  Editor  where 
required. 

•  Testing  was  conducted  on  the  individual  GMAP  system  components  as  well 
as  on  the  integrated  GMAP  system  through  a4;>plication  demonstrations. 

The  Parametric  Cooled  Turbine  Blade  demonstration  focused  on  an  FlOO  1st 
stage  turbine  blade.  An  improved  design  method  for  this  blade  was  demon¬ 
strated  by  directly  translating  design  data,  parametrically  generating  and 
modifying  geometry,  and  finally,  by  preparing  a  complete  part  model  through 
use  of  the  PDD  Editor.  The  resulting  PDD  model,  which  contained  geometric 
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and  Donshape  data,  was  a  source  for  subsequent  GMAP  blade  life  cycle 
application  demonstrations. 

The  Casting  Tooling  application  dealt  with  the  manufacture  and  inspection  of 
an  EDM  Electrode  used  to  machine  the  core  in  a  mold  as  part  of  the  turbine 
blade  casting  process.  The  entire  casting  tooling  application  consisted  of  four 
applications: 

Supplier  N/C  Machining.  Mold  Masters  Inc.,  a  Pratt  &.  Whitney 
casting  tooling  supplier  used  a  GMAP  model  to  machine  the 
electrode,  demonstrating  siqpplier  base  integration. 

Irttemal  N/C  Machining.  An  internal  Pratt  &  Whitney  group 
used  the  same  GMAP  model  to  machine  an  electrode. 

CMM  Inspection.  The  upper  surface  of  each  electrode  was 
inspected  using  GMAP  product  data. 

Automated  Optical  Inspection.  The  electrode  ribs  and  trip  strips 
were  inspected  by  Optical  Gaging  Products  Inc.  using  GMAP 
product  data. 

The  GMAP-to-IBIS  Interface  read  an  exchange  format  hie  of  a 
turbine  engine  compressor  blade  and  produced  output  files  that 
were  to  be  used  in  the  IBIS  system  for  generating  scan  plans 
that  drive  blade  inspection  operations. 

The  disk  design  application  used  the  FlOO  turbine  disk.  A 
computerized  disk  file  was  read  into  a  SUN-based  Computervi- 
sion  CADDS4X  system  where  a  solid  model  was  generated  to 
calculate  mass  properties  such  as  center  of  gravity,  weights, 
moments  of  inertia,  volumes,  and  so  on.  A  shaded  picture  was 
also  created  to  assist  in  surface  visualization.  Based  on  this 
output,  the  model  was  either  accepted  as  a  final  design,  or 
modified  and  reprocessed  through  the  above  steps. 

The  PROCAP  program  fed  process  capabilities  back  to  engi¬ 
neering  and  process  planning.  PDD  from  the  GMAP  model  were 
specified  as  parameters  in  a  search  for  similar  part  types, 
materials,  and  features.  Each  manufacturing  operation  and 
process  capability  found  to  match  the  search  parameters  were 
displayed  to  aid  the  designer  in  the  tolerancing  of  the  disk 
features. 

The  Feature-Based  N/C  Machining  and  CMM  Inspection 
Programming  application  used  form  features,  such  as  scallops 
and  bolt  hole  pattern,  and  related  product  information  such  as 
topology,  geometry,  tolerances,  and  nonshape  data  fix>m  the  disk 
PDD  modeL  Tliis  information  was  us^  to  automate  the 
generation  of  both  N/C  and  CMM  source  programs. 
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The  Disk  Forging  application  focused  on  supplier  base  integra¬ 
tion  between  Pratt  &  Whitney  and  a  major  supplier  of  disk 
forgings.  A  Supplier’s  Report  of  Nonconformance  (SRON), 
typically  used  by  suppliers  to  report  nonconformances  was  used 
to  demonstrate  the  feedback  of  process  data  closely  related  to 
the  product  definition  ftom  a  downstream  life  cycle  function 
within  a  supplier’s  facility  to  the  contractor. 

The  RFC  Interface  read  an  exchange  format  file  that  described  a 
turbine  engine  disk  and  technical  order  data,  and  produced 
Unigraphics  parts  that  were  to  be  used  in  the  RFC  system  for 
generating  scaii  plans  that  drive  disk  inspection  operations. 

The  Engine  Case  Boss  Inspection  application  was  jointly 
conducted  by  Pratt  &  Whitney  and  the  Department  of  Mechani¬ 
cal  Engineering  at  RPI,  in  Troy,  New  York.  This  application 
showed  GMAP  could  support  more  typical  industrial  parts  than 
turbine  blades  and  disks. 

The  Case  Boss  N/C  Programming  application  was  jointly 
conducted  by  Pratt  &  Whitney,  Automation  Technology  Prod¬ 
ucts,  and  IngersoU  Milling  Machine  Company.  It  demonstrated 
the  use  of  GMAP  components  to  build  and  transfer  a  product 
model  of  a  plumbing  attachment  boss. 

The  PDDI  Program  demonstrations  Display  Query  and  Classifi¬ 
cation  and  Cod^g  were  redemonstrated  to  verify  that  the  Model 
Access  Software  and  System  Translator,  enhanced  for  GMAP, 
operated  in  conjunction  with  the  original  demonstration  soft¬ 
ware  and  models. 

•  The  System  Components  Operator’s  Manual  (Cl  OM56024()(X)1U),  the 
Schema  Manager  User’s  Manual  (Cl  UM560240011U),  the  System  Translator 
User’s  Manual  (Cl  UM560240021U),  the  Model  Access  Software  User 
Manual  (Cl  560240031U),  and  the  PDD  Editor  User’s  Manual  (Cl 
56024CK}41U)  were  prepared  to  document  the  installation  and  use  of  the 
GMAP  software. 

2.5  TASK  5  —  IMPLEMENT,  MAINTAIN.  AND  DEMONSTRATE  GMAP 

•  The  GMAP  system  software  was  installed  at  McDonnell  Douglas  facilities  to 
test  the  components  as  part  of  the  development  process.  Additional  imple¬ 
mentations  of  GMAP  occurred  as  part  of  the  application  demonstrations. 

•  Very  little  system  maintenance  was  required  to  keep  the  GMAP  system 
operational  throughout  the  demonstration  period. 

•  The  successes  of  the  applications  demonstrated  across  the  product  life  cycle 
offered  several  benefits  from  implementing  GMAP  in  a  environment  similar 
to  that  in  which  the  demonstrations  were  performed. 
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•  GMAP  technology  was  demonstrated  at  the  end  of  the  program  in  five 
videotapes: 

1.  Executive  Overview 

2.  Technical  Summary 

3.  Blade  Life  Cycle 

4.  Disk  Life  Cycle 

5.  Plumbing  Attachment  Boss  Demonstrations. 

2.6  TASK  6  —  DELIVERABLE  REPORTS 

•  A  variety  of  technical  and  financial  reports  were  produced  in  accordance  with 
the  Contract  Data  Requirements  List  (DD  Form  1423)  and  the  Integrated 
Computer  Aided  Manufacturing  Life  Cycle  Documentation  Schedule.  These 
reports  are  documented  in  Section  4.  A  request  form  is  included. 
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SECTION  3 

PROJECT  ACCOMPUSHMENTS 


Section  3  describes  the  accomplishments  of  the  GMAP  effort  in  serial  order  by  Task  and 
Sul/task. 


3.1  TASK  1  —  UNDERSTAND  THE  PROBLEM 

Task  1  consisted  of  three  subtasks; 

1.1  Establish  the  Management  Planning,  Project  Schedule,  and  Scope 

1.2  Identify  the  GMAP  Needs 

1.3  Define  the  System  Requirements. 

Subtask  1.1  was  a  comprehensive  subtask  encompassing  the  establishment  of:  an  Industry 
Review  Board,  Product  Assurance/Quality  Assurance  plans,  and  coordination  with  other 
Computer  Integrated  Manufacturing  projects;  selecting  a  part  family  for  study,  and  performing  a 
h'gh  level  functional  analysis  of  the  applications  involved  in  the  life  cycle  of  the  selected  part 
ftmily. 

Subtask  1.2  included  determining  GMAP  application  interface  needs  using  a  “walkth¬ 
rough”  of  a  product’s  life  cycle.  Subtask  1.3  established  the  to-be  system  requirements  from  the 
identified  needs,  and  completed  a  State-of-the-Art  Survey  of  existing  capabilities,  identifying 
both  the  minimntn,  and  the  functional,  requirements  of  a  product  modeler. 

3.1.1  Establish  the  Management  Planning,  Project  Schedule,  and  Scope  (Subtask  1.1) 

3.1.1. 1  Management  Planning 

The  organization;  assignment  of  fimctions,  duties,  and  responsibilities;  management 
procedures  and  policies;  and  reporting  procedures  were  established  and  documented  early  in  the 
program.  Although  minor  changes  were  made  as  the  program  progressed  to  accommodate 
changes  in  personnel,  the  overall  management  structure  and  methods  for  monitoring,  reviewing, 
and  controlling  remained  the  same.  These  components  to  the  GMAP  management  plan  are 
described  below. 

3.1.1.1.1  Pratt  &  Whitney  Program  Office 

The  Pratt  &  Whitney  GMAP  Program  Office  was  managed  by  a  triad.  A  third  member. 
Program  Integrator,  was  added  to  the  typical  management  team  to  unify  efforts  and  to  aid  in  the 
transfer  of  technology.  The  following  paragraphs  indicate  the  major  areas  of  Program  Office 
responaLbilities. 
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Program  Manager 

Pratt  &  Whitney’s  Program  Manager,  Mr.  R.  Lopatka,  was  reqwnsible  for  providing 
program  visibility  to  top  management.  In  addition,  he  provided: 

•  Long-term  program  direction 

•  Monitoring  of  overall  program  progress 

•  Primary  management  for  technical  control,  resource  control,  customer 
interface,  and  contract  cost  and  schedule  performance. 

Program  Integrator 

The  Program  Integrator,  Ms.  L.  Phillips,  was  the  designated  point  of  contact  with  the 
govenunent  to  ensure  prompt  customer  response.  Other  position  responsibilities  included: 

•  Cot  'dinating  technical  activities  of  the  GMAP  subcontractor  efforts 

•  Controli,  '>g  technical  developments  to  assure  early  identification  of  problem 
areas  and  prompt  resolution 

«  Being  the  liaison  for  technology  transfer  activities  among  industrial,  academ¬ 
ic,  and  Government  programs. 

Deputy  Program  Manager 

The  Deputy  Program  Manager,  Mr.  J.  Hamill,  was  responsible  for 

•  Monitoring  implementation  of  contracts  with  GMAP  partners 

•  Financial  administrative  tasks,  (i.  e.,  cost  collection,  cost  analysis,  documen¬ 
tation,  etc.) 

•  Industry  Review  Board  meeting  management. 

3.1. 1.1 .2  Pratt  &  Whitney/ Air  Force  interface 

Interaction  between  the  GMAP  team  and  the  Air  Force  was  via  periodic  formal  program 
reviews  that  provided  oral  and  written  data  in  compliance  with  the  Contract  Data  Requirements 
List  (CDRL).  Informal  communication  was  also  provided  to  the  Air  Force  Program  Office  as 
events  in  the  program  warranted.  The  Program  Integrator  was  the  principal  contact  with  the  Air 
Force  on  technical  issues. 

3.1. 1.1 .3  Subcontractors 

Pratt  &  Whitney  utilized  three  subcontractors  to  assist  on  various  tasks  of  the  original 
GMAP:  McDonnell  Aircraft  Company  (MCAIR),  International  TechneGnnq)  Inc.  (ITI),  and 
United  Technologies  Research  Center  (UTRC).  Each  subcontractor  had  a  program  office  that 
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interfaced  with  Pratt  &  Whitney’s  Program  Integrator.  This  procedure  unified  project  activities 
and  controlled  changes  as  needed. 

The  Work  Breakdown  Structure  (WBS)  for  GMAP  was  expanded  and  an  activity  network 
was  defined.  Each  element  of  the  activity  network  was  a  work  package  that  was  the  responsibility 
of  a  the  prime  contractor  or  a  subcontractor.  Table  3-1  depicts  the  contractual  responsibilities  of 
each  of  these  subcontractors  by  Task  and  Subtask. 

Other  companies  were  involved  during  various  GMAP  system  demonstrations.  Each  such 
company  established  a  Program  Office  and  identified  the  primary  focal  point  for  interaction  with 
the  Pratt  &  Whitney  GMAP  Program  Office. 

3.1. 1.2  Project  Schedule 

In  an  iterative  process  that  took  into  account  the  task  breakdown  and  responsibility 
assignments  presented  in  Table  3-1,  the  Program  Management  Ofiice  established  Project  Master 
Schedules  that  both  Pratt  &  Whitney  and  program  subcontractors  agreed  to  follow. 

These  schedules,  depicted  in  Figures  3-1  through  3-5,  show  the  period  of  performance  for 
the  overall  program  as  well  as  for  each  of  the  technical  tasks. 

3.1. 1.3  Scope 

After  Task  responsibilities  were  assigned,  the  GMAP  participants  used  the  IDEFO  function 
modeling  methodology,  referencing  the  DesignO  and  ManufacturingO  models,  to  describe  Pratt  & 
Whitney’s  design  and  manufacturing  facilities  for  jet  engine  turbine  blades  and  disks. 

A  sample  part  family  of  jet  engine  turbine  blades  and  their  corresponding  disks  was  then 
identified.  Next,  candidate  applications  with  which  to  demonstrate  the  GMAP  system  were 
identified.  Coordination  was  established  with  other  CIM  projects  including  PDDI,  the  National 
Bureau  of  Standards’  (now  National  Institute  of  Standards  &  Technology  [NIST])  Initial 
Graphics  Exchange  Specification/Product  Data  Exchange  Standard  (IGES/PDES)  project,  and 
Computer  Aided  Manufacturing-International  (CAM-I)  projects  dealing  with  geometric  modelers 
and  ^plications  interfaces.  The  paragraphs  below  describe  the  scoping  effort  in  more  detail. 

3.1. 1.3.1  DesignO  and  ManufacturingO 

An  upper  level  GMAP  scoping  function  model  was  created  to  help  provide  an  understand¬ 
ing  of  the  role  GMAP  will  have  in  the  product  life  cycle  of  turbine  blades,  disks  and  assemblies. 
The  Air  Force’s  view  of  a  generic  aerospace  facility  is  documented  in  ICAM  DesignO  (AFWAL- 
TR-81-4023,  voL  vii)  and  ManufacturingO  (AFWAL-TR-81-4023,  voL  viii)  documents. 
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TABLE  3-1. 

TASK  BREAKDOWN  OF  SUBCONTRACTOR  RESPONSffiELITIES 


Subr.ask:  1.1 

Establish  Management  Planning,  Project  Schedule,  &  Scope 


Activity 

P&W 

HCAIR 

ITI 

UTRC 

Plem/Schedule 

Create 

PMP/PMS 

Provide 

input 

Provide 

input 

Provide 

input 

Scope 

Create 

SD 

Provide 

input 

Provide 

input 

Provide 

input 

DesignO/1 

MfrO/l 

Direct  UTEC 
Review 

— 

Gather  info 

create 

charts 

Sample  part 
family 

Create 

matrix 

— 

— 

— 

Identify 

Functional 

applications 

Look  into 

P&W  System 

Look  into 

RFC 

Look  into 

IBIS 

Conduct 

interviews 

create 

IDEF0 

Coordinate 
with  other 

CIM  activities  i 

Establish 

plan 

PDDI 

interface 

Support  as 
required 

■ 

IRB 

Establish 

IRB 

Support  as 
required 

Coordinate 

IRB 

activities 

Support  as 
required 

PA/QA 

Establish 
plan  to  be 
used  for 

GMAP 

S _ _  _ 

Provide 

PA/QA  plan 
for  work  on 
GMAP 

• 

Provide 

PA/QA  plan 
for  work  on 
GMAP 

•  -  - 

Provide 

input 

t  1  ■  — — 
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TABLE  3-1. 
(CONTINUED) 


Subtask:  1.2 


Identify  GHAP  Needs 


Activity 

P&W 

HCAIR 

ITI 

UTRC 

Establish 

INFO 

IDEFl  PO 
for  P&W 

Life  Cycle 

IDEFIX  PO  -  Cr 
Sot 

IDEFIX  PI  -  Det 
IDEFIX  P2  -  Det 
IDEFIX  P3  -  Det 
IDEFIX  P4  -  Det 

Produce  the  fit 

IDEFl  PO 
for  RFC 

late  Service  Mat 
tree  Data  List 
relop  Entity  Clas 
relop  Relation  CJ 
relop  Key  Attribi 
relop  Nonkey  Atti 

lal  IDEFl  model 

IDEFl  PO 
for  IBIS 

irial  Log  and 

sses 

Lasses 

ite  Classes 

:ibute  Classes 

Support  as 
required 

Derive  and 
analyze  GHAP 
needs 

Produce  {  Provide  I  Provide 

preliminary  1  input  I  input 

needs  list  |  1 

•  * 

Associate  benefits  to  needs 

Collect,  review  &  integrate  work 

Prioritize  needs 

Establish  specific  needs  to  be  supported 
by  GMAP 

Review  NAD 

Create 
the  NAD 

1 - 1 

Provide 
input 
for  RPC 

Review 

»  -  1 

Provide 
input 
for  IBIS 

Review 

Review 

■ 
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TABLE  3-1. 
(CONTINUED) 


Subtask:  1.3 


Define  the  System  Kequlrements 


Activity 

P&W 

MCAIR 

ITI 

UTRC 

Establish 
the  GMAP 
requirements 

The  Vrincipal  Investigator  will  review 

IDEFl  model  and  identify  entity/attribute/ 
relation  classes  needed  to  support  GMAP. 
Compare  GMAP  and  PDDI  IDEFl  models  to 
determine  PDDI  changes  and  extensions. 

Establish 

minimvun 

requirements 

Direct  & 
monitor  III 

Review 

Establish 
the  minimum 
requirements* 

Review 

Perform  the 
State-of- 
the-Art 
survey 

Monitor 

activities 

Review 

Collect 

information 

Evaluate 

findings 

Create 

report 

Provide 
input  as 
required 
Review 

Review 
Requirements 
Definition 
—  —  -1,1 

Produce  SRD 
linking  to 

RAD 

Provide 

support 

Review 

Review 

Review 

*D.  Appleton  Company  produced  follov-on  document  entitled 
"Functional  Bequlrements  of  a  Product  Modeler". 
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TABLE  3-1. 

Subtask:  2.1  (CONTINUED) 


Preliminary 

Design 

Activity 

P&V 

HCAIR 

ITI 

DTRC 

Conceptual 

Design 

Define 
alternative 
designs  for 
the 

applications 
interface 
using  PDDI 
and  results 
of  the  SRD 

Support  as 
required 

Support  as 
required 

Possible 

IDEF2 

Review 

Conceptual 

Design 

Create  Draft 
to  Conceptual 
Design 

Review 

Review 

Review 

Produce 

Preliminary 

Design 

Create  SDS, 

DS,  SIP 

Provide  input 
regarding 

Support  as 
required 

Provide 
input  as 
required 

Produce 

SDS 

Create 

SDS 

Design  PDDI 
enhancements 

Support  as 
required 

Provide 
input  as 
required 

Identify 
Enhancements 
to  total  PDDI 
System  Arch. 

Direct  & 
Monitor 

HCAIR 

Identify 

enhancements 

Support  as 
required 

Provide 
input  as 
required 

Identify 
Enhancements 
to  PDDI  EF 

Direct  & 
Monitor 

MCAIR 

Identify 

enhancements 

Support  as 
required 

Provide 
input  as 
required 

Identify 
Enhancements 
to  PDDI  Access 
Software  and 
working  form 

Direct  & 
Monitor 

MCAIR 

Identify 

enhancements 

Support  as 
required 

Provide 
input  as 
required 

Identify  linlcs 
to  corporate 
Info  Systems 

Identify 
links  at  P&W 

Provide  input 
relating  to 

RFC 

Provide  input 
relating  to 
IBIS 

IDEF  model 
support 

Produce 

DS 

Direct  & 
Monitor  MCAIR 
and  III 

Create  RFC  DS 

Create  IBIS 

DS 

— 

Establish 

System  Test 

Plan 

Create  the 
System  Test 
plan 

Provide  Input 

Provide  input 
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TABLE  3-1. 
(CONTINUED) 


Subtr.sk:  2.2 


Review  Preliminary  Design 


Activity 

P6W 

MCAIR 

ITI 

UTRC 

Review 

Present 

Present 

Present 

Assistance 

Preliminary 

Documents 

Documents 

Documents 

as  required 

Design 

at  Review 

at  Review 

at  Review 

Subtask:  2.3 


Establish  Detail  Design 


Activity 

P&V 

MCAIR 

ITI 

Establish 

Direct  & 

Create  RFC  PS 

Create  IBIS 

Product 

Monitor  MCAIR 

PS 

Specification 

and  ITI 

Establish 

Direct  & 

Create  RFC 

Create  IBIS 

Unit  Test 

Monitor  MCAIR 

UTP 

UTP 

Plan 

and  ITI 

Subtask:  2.4 


Perform  Critical  Design  Review 


Activity 

P&W 

MCAIR 

ITI 

perform 

critical 

Present 

material 

Partici 
as  Requ 

pation 

ired 
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TABLE  31. 
(CONTINUED) 

Subtask:  3.1 


Establish  Interface  to  EEC 


Activity 

P&W 

MCAIR 

i  ITI 

Produce  KFC 

Prel Imlnary 
Design 

Direct  & 
Monitor 

HCAIR 

Produce  the 
Preliminary 
Design  input 
for  4. 2. 1.3 

Reviev  RFC 

Prelimi.'ary 

Design 

Support 

HCAIR  at 

Reviev 

Present 
Documents  at 
Preliminary 
Design  Reviev 

Produce  RFC 
Detail  Design 

Direct  & 
Monitor 

MCAIR 

Expand  the 
Preliminary 
Design  for 
the  RFC  input 

Review  RFC 
Detail 
Preliminary 
Design 

—  -  _  -  i 

Support  HCAIR  i 
at  the  CDR 

Present 

Detail  Design  . 
for  RFC  at  1 

the  CDR 
(4.2.4) 

Subtask:  3.2  jg^abllsh  Interface  to  IBIS 


Activity 

P&W 

HCAIR 

ITI 

Produce  IBIS 

Preliminary 

Design 

Direct  & 
Monitor  ITI 
activities 

— 

Produce  the 
Preliminary 
Design 

Review  IBIS 
Preliminary 
Design 

Support  ITI 
at  Reviev 

Present 

Documents  at  - 
Preliminary 
Design  Reviev 

Produce  IBIS 
Detail  Design 

Direct  & 
Monitor  ITI 

Expand  the 
Preliminary 
Design  for 
the  IBIS 

Reviev  IBIS 
Detail  Design 

Support  ITl 
at  thr  CDR 

Present  Detail 
Design  for 

IBIS  at  the 

CDR  (4.2.4) 
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TABLE  3-1. 
(CONTINUED) 


Subtask:  4.1 


Construct  and  Verify  the  Application  Interface 


Activity 

P&W 

MCAIR 

ITI 

Construct 
the  GMAP 

Direct  & 
Monitor 

MCAIR  &  in 

Implement 
the  PDDI 
enhancements 

Implement  the 
IBlS  Design 

Implement 
the  GMAP 
.appJi  cation 
Interfaces 
per  ithe 
design 

Implement 
the  RFC 
design 

Test  the 
Software 

Di resit  & 
Wor.iitor 
tesitlng  in 
accordance 
with  the 

Unit  Test 

Plan 

Conduct  Unit 
Test  of  PDDI 
enhancements 
and  RFC 

Conduct  Unit 
Test  of  IBIS 

Produce  the 
Unit  Test 
Report 

Provide  test 
results 

Provide  test 
results 
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TABLE  3-1. 
(CONTINUED) 


Subtask:  4.2 


Integrate  and  Validate  the  System 


Activity 

P&W 

HCAIR 

ITI 

Construct 
the  system 

Ensure  system 
manuals  are 
created. 

Enhance  the 
system 
manuals  of 

PDDI  to 
include 

GMAP,  UM, 

OM,  MM. 

Produce  the 
application 
manuals 
for  IBIS 
Interface; 

UM,  OM, 
and  MM. 

Provide 
docimients 
for  the 

GMAP. 

Produce  the 
application 
manuals 
for  RFC 
Interface: 

UM.  OM, 
ana  MM. 

Test  the 

System 

Conduct  the 
system  test 
for  the 
selected 
application 
Interfaces. 
Document  the 
test  results. 

>  -  -  « 

Conduct  the 
PDDI  tests. 
Conduct  the 

RFC  test. 
Provide  test 
results. 

Conduct  the 
IBIS  test. 
Provide  test 
results. 
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TABLE  3-1. 
(CONTINUED) 


Subtask:  5.1,  5.2,  and  5.3 

Implement  and  Maintain  GMAP 


Activity 

P&W 

MCAIR 

ITI 

DTRC 

Implement 

GMA? 

Produce  an 
implementa¬ 
tion  plan. 

Provide  input 

Provide  input 

— 

Load  software 
for  Demo  at 

P&W  and  at 

selected 

suppliers 

Load  software 
at  SRL  for 

RFC  demo  and 
at  MCAIR  for 
PDDI  test 

Load  software 
at  SA-ALC  for 
IBIS  demo 

Maintain 

GMAP 

Maintain 
software 
loaded  to 
perform  QIAP 
Demos 

Maintain 
software 
loaded  to 
perform  PDDI 
and  RFC  Demos 

Maintain 
software 
loaded  to 
perform  IBIS 
Demo 

Project 

Perform¬ 
ance  and 
Benefits 
Analysis 

-  -  -  < 

Document 
findings  in 
a  cost  model 
describing 
the  Impact 
of  GMAP 

Write  plans 
and  conduct 
Benefit  Anal¬ 
ysis  for  GMAP 
to  RFC  Inter¬ 
face 

Assist  P&W 

Assist  P&W 
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TABLE  3-1. 
(CONTINUED) 


Subtask:  5.4 


Demonstrate  6HAP 


Activity 

P&W 

MCAIR 

ITI 

Demonstrate 
the  exchange 
format 

Demo  on 

P&W  systems 

Assistance 
as  required 

— 

Demonstrate 
the  Access 
Software 

Demo  on 

P&W  systems 

Assistance 
as  required 

— 

Demonstrate 
the  Supplier 
Base 

Integration 

Demo 

involving 

P&W 

Suppller(s) 

Assistance 
as  required 

Demonstrate 
the  GMAP 
using  the  PDDI 
Part  Classes 

Direct  & 
Monitor 

MCAIR 

Demo  on 

MCAIR 

systems 

Demonstrate 
the  GMAP-IBIS 
Interface 

Direct  & 
Monitor  ITI 

Assistance 
as  required 

Demo  on  SA-ALC 
IBIS  system 

Demonstrate 
the  GMAP-RFC 
Interface 

Direct  & 
Monitor 

MCAIR 

■  -1 

Demo  on 

SA-ALC  RFC 
system 

»  < 

— 
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FDA  366285 


Figure  3-3.  Task  2  —  Establish  Preliminary  and  Detail  Design 


Figure  3-4.  Tasks  3  and  4  —  Integrate  Existing  Functional  Applications  and  Build  and 
Integrate  the  Application  Interface 
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Figure  3-5.  Task  5  —  Implement,  Maintain,  and  Demonstrate  GMAP 

These  models  were  used  as  a  basis  for  development  of  the  GMAP  upper  level  function 
model.  The  upper  level  GMAP  function  model  was  examined  to  identify  key  fliinctions  that  were 
analyzed  in  greater  depth  during  the  detailed  activity  modeling.  GMAP  focal  points  were 
identified  from  the  upper  level  functional  model.  Certain  activities  identified  were  later 
determined  to  not  have  an  impact  on  GMAP.  The  model  was  developed  from  information 
gathered  during  interviews  with  Pratt  &  Whitney  personnel  representing  Engineering  Design 
and  Analysis,  Manufacturing  and  Inspection,  Quality  Assurance,  and  Product  Support.  The 
information  gathered  was  also  used  to  establish  a  logical  progression  into  the  next  step  of 
detailed  function  modeling,  which  concentrated  on  activities  specific  to  turbine  blades,  disks  and 
assemblies. 

Pratt  &  Whitney  operational  unit  managers,  with  broad  experience  and  knowledge  in  the 
day-to-day  operations  of  the  overall  product  life  cycle  were  interviewed  by  a  team  consisting  of 
IDEFO  modelers  from  UTRC,  a  Principal  Investigator  from  Pratt  &  Whitney,  and  supporting 
technical  staff,  as  required.  The  Principal  Investigators  were  responsible  for  arranging  the 
interviews  and  directing  the  area  of  pursuit.  The  modelers  recorded  and  transcribed  the  gathered 
data  into  IDEFO  models.  This  process  was  termed  a  modeling  walkthrough. 

The  model  captured  the  upper  level  perspective  of  the  relationships  of  the  life  cycle 
activities  within  the  turbine  blade  and  disk  part  families.  These  models,  exhibited  in  ^pendix  A, 
consist  of  three  levels,  beginning  with  GMAP/A-0  "Develop  and  Produce  Engine  Products”. 
The  resources  and  products  of  the  various  activities  are  illustrated  as  well  as  the  mechanisms 
employed  by  the  activities  and  their  controlling  factors.  These  models  were  a  formal  guide  to  the 
further  detailed  activity  modeling  phase. 
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A  hierarchical  node  tree  diagram  is  also  exhibited  in  Appendix  A.  This  node  tree  illustrates 
the  relationships  of  the  activities  from  the  upper  level  viewpoint.  It  graphically  illustrates, 
through  the  use  of  shaded  nodes,  the  scope  of  GMAP  with  respect  to  these  upper  level  functions. 

Product  data  in  the  form  of  graphic  and  text  descriptions  impact  each  of  the  six  functions 
within  the  GMAP/A3  function  (Produce  Engine  Product)  to  varying  degrees.  Results  of  the  high 
level  (scoping)  walkthroughs  indicate  that  A33  (Plan  Production)  was  the  key  technical  function 
that  used  PDD  within  manufacturing.  Therefore,  it  was  decided  that  the  detailed  walkthroughs 
would  concentrate  on  this  function.  Other  functions  would  be  evaluated  to  varying  degrees. 

3.1. 1.3.2  Select  Sample  Part  Family 

A  family  of  jet  engine  turbine  blades  and  disks  was  selected  for  the  detailed  walkthroughs. 
By  investigating  the  life  cycle  activities  associated  with  the  design,  manufacture,  and  support  of 
these  parts,  the  detailed  information  needs  were  identified.  The  part  family  consisted  of  four 
military  FlOO  engine  turbine  blades  and  their  associated  disks.  Table  3-2  provides  a  breakdown 
of  the  selected  part  family.  Table  3-3  illustrates  the  assembly  relationship  of  each  of  the  turbine 
blades  with  its  corresponding  disk. 


TABLE  3-2. 

SAMPLE  PART  FAMILY 


Part  Name 

Ensine 

Description 

Turbine  Blade 

FlOO 

Ist-atage  HPT 
Inaert  Blade 

Turbine  Blade 

FlOO-PW-lOO 

FlOO-PW-200 

Ist-sta^  HPT 

2  Piece  Shower 
Head  Blade 

Turbine  Blade 

FlOO-PW-220 

ILC*  let-stage 
Seipentine/film 
Cooled  Blade 

Turbine  Blade 

FlOO-PW-220 

ILC  2nd-stage 
Radial  Flow 
Blade 

Turbine  Disk 

FlOO-PW-lOO 

FlOO-PW-200 

lat -stage 

Turbine  Disk 

Turbine  Disk 

FlOO-PW-220 

Ist-stage 

Turbine  Disk 

Turbine  Disk 

PlOO-PW-220 

2nd-stage 

Turbine  Disk 

•  -  Improved  life  Core 

smos/u 
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TABLE  3-3. 

ASSEMBLY  RELATIONSHIP  OF  EACH  TURBINE  BLADE  WITH  ITS 


CORRESPONDING  DISK 


Ist-Stase 

Insert  Blade 

Ist-Stage 

Showerhead  Blade 

lit-Stage  Turbine  Disk 

Ist-Stage  ILC 

Ist-Stase  ILC 

Blade 

Turbine  Disk 

2nd-Stage  ILC 

2nd-Stage  ILC 

Blade 

Turbine  Disk 

4ae7C 


The  external  geometry  of  the  selected  turbine  blades  is  illustrated  in  Figures  3-6  and  3-7. 
Figure  3-6  depicts  the  concave  surface,  and  Figure  3-7  illustrates  the  convex  surface.  Each  of  the 
parts  contained  features  that  are  representative  of  the  level  of  complexity  found  throughout  the 
aerospace  industry  for  turbine  blades.  The  blades  selected  for  the  walkthrough  included  the  FIDO 
high-pressure  turbine  Ist-stage  insert  blade  design  and  the  two  piece  shower  head  design. 


The  insert  blade  illustrated  in  Figure  3-8  represents  the  widely  used  impingement  tube 
design.  The  primary  function  of  this  insert  is  to  enhance  the  convective  cooling  of  the  blade 
configuration.  The  tube  is  designed  with  an  impingement  hole  scheme,  shown  in  Figure  3-9, 
which  provides  high  velocity  jets  of  cooling  air  in  regions  of  high  heat  flux.  The  two  piece  shower 
head  blade  illustrated  in  Figures  3-10  and  3-11  is  a  newer  design  that  has  replaced  the  insert  type. 
This  blade  contains  an  integral  cooling  scheme  which  is  produced  during  the  investment  casting 
process.  This  process  requires  complex  wax  injection  molding  dies  and  ceramic  core  tooling 
which  are  designed  and  manufactured  using  a  variety  of  computer  based  tools.  This  particular 
blade  is  cast  at  Pratt  &  Whitney’s  automated  foundry  and  was  selected  based  on  the  internal 
experience  developed  within  Pratt  &  Whitney  manufacturing,  as  well  as  for  its  complex 
geometry. 
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iFi00/PW-l'00-200 
Insert  1st-Stage  Blade 


F100/PW-100-200  '  F100/PW-220  F100/PW-220  ! 

I8t-Stage  Blade  1st-St^  Blade  .  2nd-Stage  Blade 

:  2-Pieoe  Showerhead'^  .  nsion  . 

nsessM 


Figure  3-6,  Concave  Surface  of  FlOO  High-Pressure  Turbine  Blade 
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FI  00/F»W-1 00-200 
Insert  Ist-Stage  Blade 


FI  OO/PW-1 00-200 
l8t-Stage  Blade 
2-Piece  Showerhead 


F100/PW-220 
Ist-Stege  Blade 


F100/PW-220 
2nd-Stage  Blade 


n>  Mean 


Figure  3-7.  Convex  Surface  of  FIDO  High-Pressure  Turbine  Blade 
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Figure  3-8.  Impingement  Tube  Design 
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Figure  3-9.  Impingement  Hole  Scheme 
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Figure  3*10.  External  Design  of  7Vo*Piece  Sbowerbead  Blade 
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85A3937-002 


Figure  3-11.  Cutaway  View  of  the  Two-Piece  Showerbead  Blade 


The  remaining  two  turbine  blade  configurations  that  comprised  the  sample  part  family 
were  from  the  advanced  technology  FlOO-PW-220  engine  high  pressure  turbine.  This  blade  was 
selected  because  its  features  represent  the  full  range  of  simple  to  complex  features  and  geometry. 
Figure  3-12  illustrates  the  complexity  of  the  internal  design  features  of  this  blade.  The  internal 
multipass  cooling  cavities  have  two  main  passages  to  provide  effective  distribution  of  the  cooling 
air.  Integrally  cast  airflow  strips  are  provided  on  the  internal  wall  of  the  air  passages  to  increase 
the  convective  cooling  of  the  airfoil  walL  In  critical  areas,  exterxud  film  air  provides  added  cooling 
effectiveness  with  the  use  of  both  round  and  shaped  boles  which  are  produced  by  electrical 
discharge  machining. 
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FE  246668 

Figure  3-12.  Internal  Design  of  the  FlOO-PW-220  Ist-Stage  Turbine  Blade 

The  remaining  part  is  the  FlOO-PW-220  2nd-Btage  turbine  blade.  The  cutaway  in 
Figure  3-13  illustrates  the  basic  design  and  features  incorporated  into  this  configuration. 


Three  jet  engine  turbine  disks  were  selected  to  complete  the  sample  part  family.  These 
disks  were  selected  on  the  basis  of  forming  the  Ist-stage  assembly  with  the  selected  turbine 
blades.  The  insert  and  two  piece  Ist-stage  FlOO  blades  assemble  with  the  disk  illustrated  in 
Figure  3-14.  The  FlOO-PW-220  blades  assemble  with  the  disks  illustrated  in  Figure  3-15.  These 
parts  were  representative  of  blades  and  disks  inspected  in  the  Integrated  Blade  Inspection 
System  (IBIS)  and  Retirement  for  Cause  (RFC)  system. 
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Radial  Flow 
Simple  Cavity 


Internal  Pedestals 


FD  310678 


Figure  3-14.  FIDO  Turbine  Disk 
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Figure  3-15.  Disks  Associated  With  FlOO-PW-220  Blades 

3.1. 1.3.3  GMAP  Functional  Application  Selection 

Candidate  functional  applications  for  demonstration  of  GMAP  technology  were  identified 
by  applying  IDEFO  modeling  techniques  during  the  detailed  functional  modeling  walkthroughs 
described  in  Section  3.I.I.3.I.  The  data  requirements  of  the  selected  ^>plications  were  analyzed 
in  subsequent  IDEFl  work. 

The  first  level  decomposition  IDEFO  chart  from  the  scoping  efforts  illustrated  that  the 
functional  make-up  of  the  model  (including  the  functions  of  Manage,  Design,  Manufacture,  and 
Support)  was  a  logical  and  functional  structure.  This  was  the  basis  for  organizing  walkthrough 
teams. 

Three  teams  were  set  up,  combining  the  related  functions  of  Design  with  Analysis; 
Manufacturing  with  Inspection;  and  Product  Support  with  Logistics  Support. 
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Each  team  had  a  Principal  Investigator  responaible  for  overal!  GMAP  technical  work  in 
that  area,  an  expert  fimctional  modeler,  and  an  information  modeler.  The  Logistics  Support 
team  included  the  subcontractors  responsible  for  the  logistics  inspection  system  phases  of 
GMAP. 

The  interviews  focused  on  the  objectives  required  for  the  fimction  modeling  to  ensure  that 
information  transfer  from  each  interview  was  maximized. 

Approximately  100  functional  applications  were  identified,  many  of  which  were  supported 
by  computer  programs:  including  graphic  systems,  geometry  processors,  N/C  toolpath  utilities, 
cooling  hole  laser  drilling  programs,  coordinate  measuring  machine  program  generators,  fuiite 
element  stress  programs,  and  tolerance  chart  programs.  General  usage  exchange  mechanisms 
such  as  IGES,  Information  Managrr'^nt  Systems  (IMS),  and  Time  Sharing  Option  (TSO)  were 
also  identified. 

The  paragraphs  below  describe  the  function  modeling  e^orts  and  identify  the  candidate 
application^  for  each  primary  function. 

S.I.I.S.S.I  De;.’qn  and  Analysis  Walkthroughs 

The  basic  objective  of  the  design  and  analysis  walkthrough  was  to  identify  the  functional 
applications  used  in  each  area.  The  walkthrough  took  place  at  the  Pratt  &  Whitney  facilities  in 
West  Palm  Beach,  Florida.  It  involved  a  total  of  17  interviews  with  29  experts  from  various 
discipline  areas. 

In  design  and  analysis,  the  amount  of  computerization  and  electronic  interface  ranged  from 
complete  to  partial.  This  area  created  the  PDD  that  is  carried  in  both  electronic  and  paper  forms. 
The  walkthrough  also  showed  that  several  specific  design  and  analysis  disciplines  worked 
together  to  produce  a  final  part  design. 

Preliminary  Design 

Preliminary  designers  translated  the  customer’s  requirements  into  design  criteria  and 
design  tables  that  detailed  engineering  processes  used  as  input.  They  establish  engine 
configuration,  power,  performance,  life,  and  operating  temperatures.  This  iterative  process 
involved  people  from  several  engineering  groups,  and  did  not  result  in  a  final  part  definition. 

Aerodynamic  Design 

Aerodynamic  design  used  the  design  tables  as  input,  developed  the  turbine  airstream 
flowpath  through  steps  of  design  and  analysis  in  tight  internal  loops,  and  ended  up  with  a  series 
of  2-D  airfoil  profiles.  Aerodynamic  design  also  establishes  a  flowpath,  meanline  design,  and  a 
streamline  design. 

This  area  was  highly  automated,  such  that  the  output  of  one  program  became  the  mput  to 
the  next.  Tbe  level  of  PDD  involved  was  not  great,  but  the  output  (the  data  points  on  the 
external  surface  of  the  airfoil)  of  the  discipline  was  tbe  first  product  defining  data  that  was  seen. 
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Durability  Design 

Durability  di  jign  was  responsible  for  the  cooling  design  of  turbine  blades.  The  task  focused 
on  developing  a  cooling  scheme,  calculating  the  required  flow,  developing  core  geometry,  and 
locating  cooling  film  holes.  The  process  involved  the  use  of  heat  transfer,  stress,  flow,  and  finite 
element  analyses. 

This  area  was  moderately  computerized,  but  not  as  sequential  as  aerodynamics.  The  rate  of 
technology  evolution  in  turbine  design,  and  therefore,  cooling  scheme  complexity,  has  led  this 
discipline  away  from  traditionally  effective  applications.  It  required  manual  data  manipulation  or 
new  computer  applications. 

Structures  Technology 

The  structures  group  performed  in-depth  analyses  when  the  design  became  mature.  These 
verification  analyses  were  complicated  and  time  consuming,  and  tests  ranged  trom  generic 
statistical  analyses,  through  ^ite  element  modeling,  to  specific  life  calculations.  Design 
verification  analyses  included  creep-rupture,  crack  growth,  fracture  mechanics  and  the  full 
spectrum  of  plastic  and  elastic  stress  analyses. 

This  discipline  was  highly  automated,  and  the  data  defining  the  material  and  geometry  of 
the  part  was  the  main  input.  However,  an  extensive  integrated  computerized  interface  did  not 
exist  between  the  structures  people  and  the  component  designers. 

Mechanical  Design  for  Blades 

The  mechanical  designer  was  ultimately  responsible  for  the  part  design.  For  turbine  blades, 
3-D  models  were  created  from  the  internal  and  external  cross-sections.  This  was  to  evaluate  the 
breakout  between  holes  and  surfaces  as  designed,  and  often  required  iteration.  The  mechanical 
designers  also  developed  the  design  of  the  blade  platform  geometry  and  the  transition  from  the 
airfoil  to  the  platform.  Blade  geometry  below  the  platform  was  also  developed  here;  the  internal 
cooling  passage,  and  the  external  shank  geometry.  The  mechanical  designer  continued  to  define 
the  blade  further,  and  developed  the  mass  property  analysis. 

Mechanical  Design  for  Disks 

Disks  were  designed  in  the  mechanical  design  area.  The  mission  requirement  limitations 
and  other  design  criteria  from  preliminary  design  were  used  to  produce  a  preliminary  disk  profile. 
This  profile  was  then  analyzed  and  optimized.  The  disk  broach  geometry  was  designed  from  the 
given  blade  mass  properties.  This  configuration  was  banded  to  produce  the  final  blade 
attachment  geometry. 

Drafting 

The  drafting  area  had  the  responsibility  to  commvuoicate  the  design  intent  This  included 
converting  the  as-designed  hot  dimensions  to  the  as-made  cold  dimensions.  In  doing  this,  the 
critical  design  tolerances  were  reviewed  and  dimensioning  was  established.  The  drafting  area 
assisted  in  developing  the  core  tranritisn  from  airfoil  to  attachment  in  a  3-D  model.  Several 
CAD/CAM  files  were  derived,  produced,  and  included  in  the  design  review  process. 
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Design  Review 

The  entire  design  process  was  finalized  at  a  Design  Review.  The  complete  spectrum  of 
interests  involved  with  that  part  played  decisive  roles  in  the  approval  process.  The  disciplines 
concerned  included  aerodynamics,  durability,  structures,  drafting,  producibility,  inspectability, 
meteilurgy,  and  quality  assurance. 

Wfilkthrough  Results 

This  walkthrou^  resulted  in  a  function  model  that  identified  potential  ^>plications  that 
were  later  investigated  during  the  information  modeling.  At  the  lowest  functional  level,  the 
mechanisms  identified  were  indeed  application  programs,  and  thus,  the  model  terminated  at  this 
level. 


The  full  list  of  functional  computer  applications  identified  by  the  design  and  analysis 
walkthrough  is  shown  in  Table  3-4.  More  than  enough  applications  from  the  disciplines  involved 
were  identified,  and  there  was  comprehensive  coverage  of  the  part  life  cycle. 

3.1.1.3.3.2  Manufacturing  and  inspection  Walkthroughs 

Identification  of  manufacturing  and  inspection  candidate  functional  applications  also 
occurred  with  the  IDEFO  analysis  described  previously.  The  manufacturing  and  inspection 
V  alkthroughs  were  conducted  at  five  different  facilities  throughout  Connecticut  and  in  Georgia. 
These  facilities  illustrated  the  diversity  and  decentralization  of  the  manufacturing  effort; 

•  Automated  Casting  Facility,  Middletown,  Connecticut  Highly  automated, 
this  facility  produced  castings  for  the  FlOO  Ist-stage  turbine  blade  (shower- 
head  configuration).  This  was  the  only  turbine  blade  in  the  sample  part  family 
cast  by  Pratt  &  Whitney.  All  of  the  other  turbine  blades  were  cast  by 
suppliers. 

•  Experimental  Foundry  Facility,  Manchester,  Connecticut.  This  facility 
developed  new  casting  technologies  to  support  advanced  turbine  blade 
designs.  It  was  heavily  involved  in  developing  the  casting  processes  used  at 
the  Automated  Casting  Facility  in  Middletown,  Connecticut. 

•  Columbus,  Georgia.  This  facility  was  responsible  for  high  technology  forging 
of  the  FlOO  high  pressure  turbine  disks.  It  was  also  responsible  for  the  initial 
(sonic  shape)  machining  and  ultrasonic  inspection  of  these  parts.  The  facility 
was  highly  automated  and  had  a  number  of  computerized  iq>plications 
suitable  for  data  analysis  and  possible  GMAP  demonstrations. 

•  North  Haven,  Connecticut.  All  parts  in  the  sample  part  family  were  machined 
and  finished  at  this  facility.  It  performed  many  functions  on  the  parts  such  as 
grinding,  turning,  milling,  broaching,  coating,  and  final  inq)ection. 

•  East  Hartford,  Connecticut  All  centralized  functions  within  the  Pratt  & 
Whitney  manu&cturing  environment  were  performed  at  this  facility.  It 
provided  key  technical  and  administrative  siqjport  functions,  along  with 
assembly  of  the  blades  and  disks. 
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TABLE  3-4. 

DESIGN  AND  ANALYSIS  FUNCTIONAL  APPUCATONS 


Preliminary  Deeign 

—  Sute-of-the-art  Performance  Program 

—  Parametric  Engine  Pfogram-12  Vehicle  Anabvia  Miasion  Program 

Aerodynamic  Design 

—  Floirpath  Generator/Parameter  Solver 

—  Meanline  Design 

—  Streamline  Design 

—  Airfoil  Design 

—  Curved  Line  Fairing  and  Stress 

—  Transonic  Potential  Flow  —  Pressure  Distribution 

—  Boundary  Layer  Analysis 

—  3-D  Time  Matching  Pressure  Distribution 
-  Internal  Geometry  Definition 

Oui.SilMy  Design 

—  Inumal  Flow  Program 

—  Heat  Transfer  Program 

—  Finite  Element  Breakup  Program 

—  Stress  Analysis 

—  Miasion  Life  Proration 

—  Creep-Rupture  Life  Evaluation/Low-Cycle  Fatigue  (LCF)  Life  Evaluation 

—  Curved  line  Fairing  and  Stress 

Structures 

—  Plane  Elasticity  Integral  Equation  Analysis 

—  Generalized  2-D  and  3-D  Finite  Element  Static  and  Dynamic  Stress 

—  Generalized  Disk  Stress  Analysis 

—  Generalized  Shell  Program 

—  Biaxial  Stress  Distribution  in  Disk  Rim  Sbts 

—  2-D  and  3-D  Nonlinear  Elastic  Analysis  of  Solids,  Shells,  and  Beams 

—  Temperature  Averaging  Program 

—  Curved  Line  Fairing  and  Stress 

—  LCF  Regression  Data  Program 

—  Variable  Reduction  Program 

—  Statistical  Analysis  System 

—  LCF  Life  Prediction  Routine 

—  LCF  Life  Prediction  Program 

—  Through — Crack  Predictions  at  Stieas  Concentration  Regions 

—  General  Purpose  Spectrum  Loading  Program 

—  Tension  and  Bending  Crack  Growth  Program 

—  Linear  Elastic  Fracture  Mechanics  Program 

—  Preliminary  Disk  Profile  Generator 
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TABLE  3-4. 

DESIGN  AND  ANALYSIS  FUNCTIONAL  APPLICATONS  (CONTINUED) 


Mechanical  Deaign 
—  Cycle  and  Streea  Program 
—  Fir-Tree  Synthesia 
—  Preliminary  Diik  Profile  Generator 
—  Miasion  Analygia  Program 
—  Elastic  Streaa  Program 
—  Temperature  Averaging  Program 
—  Finite  Element  Streaa  Analyaia 

Drafting 

—  Computer  Graphics  System  A  (Drafting) 

—  Computer  Grqthica  System  B  (Drafting) 

—  Curved  Line  Fairing  and  Streaa 
—  EMD  Generator  Interface 
—  2-D  Geometry  Processor 
—  Airfoil  Drafting  Utilities 
—  Cooling  Hole  Pattern  Generator 
—  Point  Redistribution  Program 

—  Airfoil  Manipulation  Programs _ 

Bsoan/u 

Manufacturing  was  broken  into  six  major  functions  that  were  investigated  to  identify  and 
track  the  use  of  PDD.  The  major  functions,  illustrated  in  Figure  3*  16,  are  briefly  described  below. 

•  “Plan  for  Manufacture”  was  the  overall  planning  and  integration  process 
within  the  manufacturing  function.  It  consisted  of  activities  such  as 
developing  production  start-up  plans,  sourcing,  integration,  and  monitoring 
overall  performance.  It  was  primahly  an  administrative  function  and  was  a 
conduit  of  PDD. 

•  “Make  and  Administer  Schedules  and  Budgets”  provided  preliminary  sched¬ 
ules  and  budgets  and  refined  them  as  production  details  were  supplied  from 
the  “Plan  Production”  function. 

•  “Plan  Production”  was  the  key  technical  and  engineering  function  and,  as 
such,  was  the  primary  user  of  PDD.  Results  of  the  walkthroughs  indicate  that 
all  other  major  functions  relied  on  this  fimction  as  the  primary  source  of 
technical  information  relative  to  the  manufacturing  process.  This  function 
was  re^nsible  for. 

•  Planning  and  scheduling  production  methods 

•  Providing  and  documenting  manufacturing  and  inspection 
instructions 

•  Devek^ing  tooling  requirements  and  providing  tool  designs 
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•  Programming  all  automated  manufacturing  and  inspection 
devices 

•  Providing  technical  liaison  with  design  engineering  and  with 
tooling  8iq>pliers. 

•  “Provide  Production  Resources"  provided  facilities,  equipment,  tooling,  and 
personnel  to  manufacture  the  product.  It  was  primarily  an  administrative 
function  and  relied  on  the  “Plan  Production”  function  for  technical 
information  and  analysis. 

•  “Obtain  Manufacturing  Materials”  included  all  phases  of  material  acquisition 
from  purchasing  through  in-house  storage  and  distribution. 

•  “Produce  Engine  Product”  included  the  actual  manufacturing  and  inspection 
of  engines,  parts,  and  spares.  It  was  also  a  primary  user  of  PDD.  However,  the 
results  of  the  walkthroughs  showed  that  it  relied  on  the  “Plan  Production” 
function  as  its  primary  source  of  PDD  and  for  technical  instructions. 

Vk'alkthrough  Results 

In  general,  it  was  found  that  manufacturing  functions  were  decentralized  and  highly 
dispersed.  Manufacturing  functions  associated  with  the  sample  part  fanuly  were  distributed 
among  the  five  different  facilities.  This  did  not  include  the  role  of  suppliers.  While  this  presented 
a  significant  logistical  problem  in  accomplishing  the  walkthroughs,  it  also  pointed  out  a  benefit 
to  using  electronic  PDD.  Almost  all  of  the  interviewees  indicated  a  primary  need  to  access  this 
kind  of  information  on  the  computer,  rather  than  rely  on  the  flow  of  paper. 

Manufacturing  was  characterized  by  islands  of  automation.  A  number  of  the  facilities,  such 
as  the  Automated  Casting  Facility  and  the  Columbus,  Geor^  facility,  were  highly  automated, 
while  others  were  not.  Further,  some  functions,  such  as  N/C  programming  and  dimensional 
inspection,  were  highly  automated  while  other  key  functions  were  not. 

Suppliers  were  highly  involved  in  the  manufacturing  prooes.  They  bad  a  principal  role  in 
the  production  of  the  following: 

•  Airfoil  castings 

•  Disk  forgings 

•  Raw  materials 

•  Design  and  development  of  production  tooling. 

Interviewees  responsible  for  dealing  with  suppliers  generaUy  indicated  that  electronic  PDD 
would  benefit  suppliers  using  CAD/CAM  equipment  and  would  provide  an  incentive  to  those 
suppliers  which  did  not  currently  use  this  equipment. 
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Production  planning  was  the  key  function  in  the  development  and  use  of  PDD.  The 
walkthroughs  identified  this  function  as  the  key  technical  and  engineering  function  within 
manufacturing.  AU  of  the  other  functions  relied  on  production  planning  as  their  primary  source 
of  technical  information  and  analysis. 

The  manufacturing  and  inspection  walkthroughs  identified  the  key  functions  listed  in 
Table  3-5  as  those  that  should  ^  included  in  the  information  modeling  analysis. 


TABLE  3-5. 

MANUFACTURING  AND  INSPECTION  FUNCTIONAL  APPLICATIONS 


Manutaetufing 

—  G>inputcr  Aid«d  Process  Planning 

—  Tolersince  Chart  Pfogram 

—  Computer  Graphics  Systam  A  (N/C) 

—  Computer  Graphics  System  B  (N/C) 

—  Airfoil  Manipulation  Programs 

—  2-D  Geometry  Processor 

—  T'UTS'ng  Irt'rerti^e  Program  (N/C) 

—  Automatically  Programmed  Tools  (N/C) 

—  N/C  Toohmth  Plotting  Utility 

—  N/C  Cooling  Hole  Laser  Drilling  Program  Generator 

Inapactkm 

—  2-D  Geometry  Processor 

—  Coordinate  Measuring  Machine  Program  Generator 

—  Scan  Program  Generator 

Qanaral  Usage 

—  Network  Communicatioirs  Package 

—  IGES 

—  Inter-Divisional  Exchange  System 

—  Information  Management  System 

—  Time-Sharing  Option _ 

dU02/lt 


3.1.1.3.3.3  Product  Support  and  Logistics  Support  Walkthroughs 
Product  Support 

As  with  the  other  two  groups,  the  IDEIFX)  fimctional  modeling  approach  was  used  in 
walkthroughs  of  Pratt  &  Whitney’s  product  support  functions. 

Product  Support  consisted  of  all  support  activities  necessary  to  service  Pratt  &  Whitney 
engine  customers.  It  provided  technical  information  and  instructions,  processed  warranty  claims, 
provided  pricing  information,  processed  orders  for  q>are  parts,  established  logistic  requirements, 
and  forecast  future  parts  needs. 

The  Product  Support  walkthrough  showed  that  there  were  four  major  activities,  illustrated 
in  Figure  3-17,  necessary  to  provide  customer  service.  These  activities  were:  Provide  Technical 
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Support.  Process  Spare  Parts  Orders,  Determine  Logistics  Needs  of  the  Customer,  and  Plan 
Future  Spare  Parts  Requirements. 

•  “Provide  Technical  Siq>port”  was  performed  1^  the  technical  siqiport  staff 
and  included  all  the  technical,  logistic,  rqwir,  and  equ^ment  scqqwrt 
activities.  This  fimction  involved  all  customer-related  technical  problems.  It 
also  included  designing  qiecial  ground  siqiport  equipment,  establishing  and 
administering  the  warranty  program,  and  turning  out  the  finished  technical 
orders. 

•  “Sell  Spare  Parts**  was  performed  by  the  quue  part  sales  staff  dealing  with 
customer  requests  for  parts  and  information.  This  fimction  included  reqxtnd- 
ing  to  customer  queries  and  order  requests  as  well  as  the  processing  of  orders 
for  spare  parts  and  equipment. 

•  “Determine  Customer  Logistics  Needs**  was  performed  by  the  technical 
support  staff  and  involved  an  assessment  of  customer  repair  requirements 
compared  to  current  capabilities.  This  information  was  used  to  determine  any 
shortfall  of  material  or  equipment  required  to  support  maintenance  or  repair 
of  engines.  It  comprised  an  analysis  of  customer  orders  and  product 
information,  a  review  of  ground  support  equipment  designs  and  customer 
capabilities  to  identify  logistic  needs,  and  documentation  of  logistics  support 
requirements. 

•  ‘’Provide  Spare  Parts  Planning**  was  performed  hy  the  spare  parts  sales  staff 
and  involved  all  planning  related  to  providing  spare  parts.  This  fimction 
included  creating  a  forecast  of  qjare  parts  demand,  preparing  a  master 
forecast  for  production  scheduling,  and  providing  price  lists  and  specific  price 
quotations. 

Logistics  Support 

The  walkthrough  methodology  was  used  to  examine  logistics  support  in  general,  and  to 
study  two  specific  areas  within  logistics  dealing  with  inspection  processes.  One  dealt  with  blades, 
the  Integratid  Blade  Inspection  System  (IBIS);  the  other  with  disks.  Retirement  for  Cause 
(RFC).  The  general  walkthrough  was  conducted  at  SA-ALC  at  Kelly  Air  Force  Base,  San 
Antonio,  Texas.  The  two  specific  studies  were  based  on  discussions  with  personnel  at  Systems 
Research  Laboratories,  in  Da}rton,  Ohio,  and  at  General  Electric,  in  Evandale,  Ohio  as  well  as 
fiom  information  gathered  at  SA-ALC. 

The  general  analysis  of  the  logistics  support  fimctions  was  conducted  first.  The  goal  of  this 
portion  of  the  walkthrough  was  to  understand  product  maintenance  activities  performed  by  users 
in  the  field. 
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Logistics  support  involved  the  disassembly,  inspection,  service,  repair,  and  reassembly  of 
in-service  aerospace  products.  The  primary  concern  of  the  GMAP  axudysis  was  the  return  of 
sendced  products  to  operation.  The  term  “product”  was  used  to  include  the  aerospace  product  as 
well  as  the  supporting  systems. 

Logistics  support  at  the  SA-ALC  was  found  to  consist  of  five  major  activities;  Management; 
Planning;  Schedules  and  Budgets  Administration;  Product  Maintenance;  and  Assembly  and 
Test.  The  nugor  area  emphasized  during  the  walkthrough  was  Product  Maintenance. 


Product  Maintenance  encompassed  the  actual  hands-on  maintenance.  Component  disas¬ 
sembly,  inspection,  and  repair  and/or  retirement.  The  investigation  of  the  Product  Mmntenance 
area  uncovered  the  four  major  activities  shown  in  Figure  3-18:  Planning;  Provide  Maintenance 
Resources;  Obtain  Maintenance  Materials;  and  Perform  Actual  Maintenance. 


FDA  36628S 


Figure  3-18.  Support  and  Perform  Turbine  Blade  and  Disk  Maintenance 

Planning,  Provide  Maintenance  Resources,  and  Obtain  Maintenance  Materials  closely 
resembled  the  activities  of  a  manufacturing  facility.  Detailed  maintenance  instructions  were 
created  to  guide  maintenance  processes.  The  majority  of  these  instructions  were  created 
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maniially,  derived  &om  information  obtained  from  en^eering  drawings  and  from  technical 
orders  si'.pplied  by  the  manufacturer. 

IBIS 


D3IS  provided  an  automated  blade  inspection  capability  for  the  lopstics  support  facility.  It 
wa'i  a  more  repeatable  and  less  subjective  ittspection  srith  increased  capability.  It  also  allowed 
inipection  to  keep  pace  with  the  technological  advances  in  jet*engine  blade  design  and 
rjaf'ufacture. 

IBIS  consisted  of  several  of  distinct,  integrated  submodules.  There  were  three  inspection 
submodxiles,  illustrated  in  Figure  3*19,  that  performed  the  actual  inspection.  These  were  the 
Fluorescent  Penetrant  Inspection  Module,  the  Infrared  Inspection  Module,  and  the  X-Ray 
Inspection  Module.  In  addition,  the  Information  Computer  System  was  the  manager  of 
inspection  data  and  inspection  results.  The  Automated  Fluorescent  Penetrant  Pre-Processing 
Module  automated  the  application  of  fluorescent  penetrant  to  parts  that  were  to  be  inspected 
with  the  Fluorescent  Penetrant  Inspection  Module.  This  helped  to  ensure  consistent  and 
accurate  fluorescent  penetrant  inspections. 

R  'w  IriCpccbor.  Systoiii 

The  RFC  system  was  an  automated,  robotics-based  inspection  system  developed  by 
Systems  Research  Laboratories  in  Dayton,  Ohio  for  the  SA-ALC.  RFC  was  used  to  detect  engine 
disk  surface  and  internal  flaws  using  eddy  current  and  ultrasonic  Nondestructive  Evaluation 
techniques. 

RFC  extended  the  life  of  parts  by  measuring  and  evaluating  actual  in-service  flaw  sizes. 
These  measured  flaw  sizes  were  used  as  the  basis  for  retiring  disks,  as  opposed  to  using 
conservative  engineering  predictions. 

The  RFC  system  consisted  of  two  automated  cells.  One  cell  used  an  eddy  current 
instrument  and  technique  to  detect  surface  flaws.  The  second  cell  used  an  ultrasonic  instrument 
to  detect  subsurface  flaws. 

The  RFC  system  major  functions  included  generating  a  scan  plan  for  the  inspection  of  disks 
and  creating  an  analysis  software  package  to  analyze  the  inspection  data.  The  analysis 
determined  the  disks  status  —  accept,  reject,  or  incomplete.  The  process  is  graphically  depicted 
in  Figure  3-20. 

3.1. 1.3.4  Establish  Coordination  With  Other  CIM  Projects 

Pratt  &  Whitney  investigated  other  Air  Force  Materials  Lab  CIM  Branch  programs  as  well 
as  industry  efforts  in  an  attempt  to  establish  technology  transfer  opportunities.  Coordination  of 
GMAP  with  projects  with  similar  objectives  would  provide  additional  direction  to  the  program 
and  enable  GMAP  to  reap  the  benefits  of  similar  work  completed  or  in  process. 
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Figure  3-19.  Support  and  Use  IBIS 
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Initially,  GMAP  looked  at  several  programs  including: 

•  Product  Definition  Data  Interface  (PDDI) 

«  Integrated  Information  Support  System  (IISS) 

•  Intelligent  Task  Automation  (ITA) 

•  Factory  of  the  Future  (FOF) 

•  National  Bureau  of  Standards*,  later  changed  to  the  National  Institute  of 
Standards  and  Technology  (NIST),  Initial  Graphics  Exchange  Specification 
and  Product  Data  Exchange  Specification  (IGES/PDES) 

•  Computer  Aided  Manufacturing-International  (CAM-I) 

•  Integrated  Design  Support  System  (IDS). 

The  process  of  identifying  the  most  appropriate  projects  led  the  GMAP  team  to  concentrate 
( n  PDDI  and  NIST  "ssociated  programs.  Appendix  B  presents  a  compendium  of  the  various 
technology  transfer  efforts  conducted. 

3.1.1.4  Industry  Review  Board 

An  Industry  Review  Board  (ERB)  was  established  to: 

•  Review  the  progress  of  GMAP 

•  Assess  the  technical  direction  of  the  project 

•  Offer  advice  from  a  broad  base  of  industrial  background  and  experience 

•  Provide  an  important  vehicle  to  assist  with  the  transfer  of  GMAP  technology 
to  industry  in  general. 

3.1.1. 4.1  Membership 

Pratt  &  Whitney  solicited  several  organizations  to  become  members  of  the  IRB.  The  IRB 
originally  consisted  of  12  member  organizations  —  three  from  each  of  four  categories:  gas  turbine 
engine  manufacturers,  air^ame  manufacturers,  computer  system  manufacturers,  and  major  gas 
turbine  engine  subcontractors.  As  the  program  evolved,  some  members  withdrew  for  various 
reasons  and  others  were  added.  The  final  makeup  of  the  IRB  is  presented  in  Table  3-6. 
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TABLE  3-6. 

IRB  MEMBERSHIP 


Chairman 

Mr.  Gecrgc  J.  Hess 
Ingeisoll  Milling  Machine  Co. 

Sacralary 

Jason  (Jack)  Lemon 

international  TechneGroup  Incorporated 

Mambara 

Robert  Badgett 
ComputerVision  Corporation 

Jack  Conaway  and  Ulrick  Flatau 
Digital  Equipment  Corporation 

C.  'vin  W.  Emmerson 
Aliu  -n  Gas  Turbine  Division 

S.  J.  (Jeane)  Ford 
International  TechneGroup  Inc. 

Donald  J.  Gregory 
General  Ellectric/AEBG 


Mambara 

Jim  Hutto 

Intergraph  Corporation 

Chris  Klomp  and  Mile  McClure 
Boeing  Company 

Robert  Krakowaky  and  Stan  Pickford 
Wyman-Gordon  Company 

Don  Manor 
Deere  &  Company 

Robert  L.  McMahon,  Jr. 

General  Dynamics 

Donald  Moracz 
Textron  M&MTC 

Chet  Moutrie 

Control  Data  Corporation 

Ed  Schumacker 

Avco  Aeroatructures  Textron _ 

temajit 


Mr.  G.  Hess,  Vice  President  —  S3rstems  and  Planning  for  IngersoU  Milling  Machine 
Company,  agreed  to  be  the  Chairman  of  the  IRB.  Mr.  Hess  joined  IngersoU  in  1974  to  manage  aU 
systems  and  data  processing,  and  was  elected  vice  president  in  1981.  Under  Mr.  Hess’s 
leadership,  IngersoU  was  chosen  as  the  recipient  for  the  second  annual  “LEAD”  award  in  1982  by 
the  computer  and  Automated  Systems  Association  of  the  Society  of  Manufacturing  Engineers 
(CASA/SME).  Mr.  J.  Lemon,  President  of  ITI,  agreed  to  be  Secretary  of  the  IRB. 

3.1. 1.4.2  Strategies 

There  were  several  strategies  used  to  assure  a  successful  IRB.  First,  since  the  GMAP  IRB 
was  also  the  forum  to  provide  industry  feedback  to  the  extension  of  the  PDDI  project,  there  was 
an  overlapping  of  members.  That  is,  the  GMAP  IRB  contained  some  members  frc  .  i  the  PDDI 
IRB. 


Also,  a  member  was  selected  who  could  provide  an  effective  interface  to  the  NIST  PDES 
program.  It  was  expected  that  GMAP  would  be  able  to  contribute  to  PDES  in  PDD  related  areas 
such  as  file  size,  processing  speed,  functionality  of  information,  elimination  of  redundancy. 

The  IRB  representative  from  each  of  the  participating  con^[>anie8  was  expected  to  provide 
additional  people  fxom  his  or  her  firm  that  have  expertise  in  the  agenda  material  being  discussed. 
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3.1.1.4.3  IRB  Meetings 

There  were  six  ERB  meetings.  Each  meeting  reviewed  the  technical  progress  of  the  program 
and  provided  a  forum  for  technical  guidance.  The  meetings  took  place  in  the  time  frames,  with 
topic  areas  as  indicated  in  Table  3-7. 


TABLE  3-7. 
IRB  MEETINGS 


Date 

Topic 

1.  Febnuify  1986 

Review  technical  approach  and  acopinf 

2.  September  1986 

Review  Needs  Analysis  Work,  State-of-the-Ait 
findings,  and  technical  progress 

3.  March  1987 

Review  Task  1  documents,  interiiace  plans,  and  design 
approaches 

4.  December  1987 

Review  minimum  requirements  of  a  product  modeler 
and  related  issues 

5.  March  1988 

End  of  PDDI  Extension  debriefing 

6.  September  1988 

Review  results  and  lessons  learned 

ft»B02/lS 


3.1.1.4.3.1  First  IRB  Meeting 

The  first  IRB  meeting  was  held  February  5  and  6, 1986,  in  West  Palm  Beach,  Florida.  The 
meeting,  attended  by  approximately  60  people,  was  divided  into  six  sessions.  Session  one  was  an 
introductory  session,  with  welcoming  remarks  and  introductions  of  the  members  and  observers. 
The  group  was  briefed  on  the  purpose  for  the  board  and  given  a  general  overview  of  the  program. 

Session  two  focused  on  the  roles  of  the  subcontractors,  program  objectives  and  anticipated 
results  from  the  first  two  tasks. 

Session  three  concentrated  on  imderstanding  the  features  of  the  product  family  of  the 
program  and  correlation  with  PDD  and  geometric  representation.  An  overview  of  the 
walkthrough  methodology  was  presented  in  this  session. 

The  fourth  session  focused  on  the  results  of  the  IDEFO  part  walkthroughs  for  Engineering 
and  Manufacturing.  The  session  also  presented  the  status  of  Task  1. 

Session  five  provided  details,  plans,  and  status  for  the  state-of-the-art  (SOA)  survey  and 
the  documentation  on  the  Minimum  Requirements  for  a  Geometric  Modeler.  Attendants  were 
also  briefed  on  the  work  planned  and  status  for  the  RFC  and  IBIS  logistics  ^plications. 

Session  six  was  devoted  to  the  IRB’s  membership  providing  input  and  direction  for  the 
program.  The  group  was  divided  into  four  smaller  groups,  and  each  was  asked  to  address  an  issue 
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that  the  GMAP  team  felt  could  have  an  impact  on  the  program.  All  commepta  received  were  very 
favorable ,  and  all  present  were  pleased  with  the  two-way  communication  and  interaction  of  the 
group. 


3.1.1.  t.3.2  Second  IRB  Meeting 

The  second  IRB  meeting  was  held  9  and  10  September  1986  in  Hartford,  Connecticut.  The 
m'eting  was  attended  by  approximately  100  people  representing  a  broad  cross  section  of 
American  industry.  Included  were:  aerospace  and  nonaerospace  firms,  computer  manufacturers, 
CAD/CAM  suppliers,  universities,  and  the  military.  The  primary  theme  of  the  meeting  was  to 
present  findings  of  the  walkthroughs  and  show  the  needs  for  the  selected  part  family. 

The  meeting  was  divided  into  seven  sessions.  Session  one  featured  welcoming  remarks  and 
introductions  of  the  IRB  Chairman,  Mr.  G.  Hess.  The  group  was  briefed  on  the  status  of  the 
program,  followed  by  a  review  of  the  last  IRB  meeting,  presented  1^  IRB  secretary  Mr.  J.  Lemon 
from  International  TechneGroup  Incorporated  (ITI). 

Session  two  focused  on  the  walkthrough  investigation  that  was  conducted  for  the  needs 
analysis.  Presentations  were  given  on  the  life  cycle  fimctional  areas  investigated:  Design  and 
Analysis,  Manufacturing  and  Inspection,  Product  Support,  and  Logistic  Support.  These 
presentations  reviewed  the  as-is  environment,  discussed  the  to-be  environment,  and  indicated 
V  nat  PDD  needs  had  to  be  met. 

Session  three  detailed  the  data  needs  and  presented  the  categorized  classes  established 
during  the  modeling  efforts.  These  classes  were:  Geometry,  Topology,  Features,  Tolerance, 
Nonshape  and  Notes,  and  Administrative  and  Assembly. 

The  fourth  session  was  a  workshop  which  provided  the  IRB  members  and  observers  with  a 
chance  to  interact  on  issues  surrounding  the  needs  analysis.  Six  groups  were  formed  and  were 
asked  to  address  specific  issues  that  could  impact  the  program. 

Session  five  was  an  overview  on  the  initial  findings  of  the  State-of-the-Art  (SOA)  survey. 

Session  six  was  devoted  to  presentations  on  other  programs  that  were  related  to  GMAP. 
These  efforts  included:  Computer-aided  Acquisition  and  Logistics  Support  (CALS),  NIST, 
IGES/PDES,  and  American  National  Standards  Institute  (ANSI)  Y14.26.  The  last  session 
provided  an  overview  of  the  PDDI  extension  contract. 

3.1.1.4.3.3  Third  IRB  Meeting 

The  third  IRB  meeting  was  held  29  and  30  April  in  Deerfield  Beach,  Florida.  This  meeting 
was  attended  by  approximately  75  people  representing  organizations  similar  to  those  at  meeting 
2.  The  primary  objective  of  the  meeting  was  to  review  the  GMAP  conceptual  design.  Other  major 
items  included  presentations  on  both  the  proposed  demonstrations  for  GMAP  and  the  PDDI 
extension  contract. 

The  meeting  was  divided  into  five  sessiona  Session  one  featured  opening  remarks  from  Mr. 
R.  Lopatka,  Pratt  &  Whitney’s  GMAP  Program  Manager.  The  IRB  Chairman  then  provided 
welcoming  remarks  and  introduced  the  IRB  members  and  observers.  Lt.  E.  Gunther,  the  new 
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United  States  Air  Force  (USAF)  GMAP  Program  Manager,  followed  with  a  welcome  to  all 
attendants.  This  session  ended  with  a  presentation  on  the  current  status  of  the  GMAP  contract 
which  included  a  briefing  on  the  technical  progress  that  occurred  since  the  September  1986 IRB 
meeting. 

Session  two  consisted  of  two  presentations  that  completed  the  technical  work  in  Task  1  of 
GMAP.  The  first  of  these  was  a  final  report  on  the  SOA  survey.  It  focused  on  current  technology, 
needed  technology,  technology  trends,  and  analysis  results.  The  second  Task  1  presentation  was 
a  report  on  the  minimtim  product  modeler  required  to  support  the  jet  engine  turbine  blade  and 
disk  life-cycle. 

Session  three  detailed  the  GMAP  PDD  schema  development  and  content.  The  opening 
presentation  in  this  session  ofiered  an  overview  of  the  IDEF  methodology  employed  which 
involved  model  verification,  and  schema  specification  using  EXPRESS.  Also  included  was  a 
scope  comparison  of  GMAP  to  the  current  PDES  work.  The  second  part  of  this  session  consisted 
of  descriptions  of  the  GMAP  PDD  schema  content. 

The  fourth  session  focused  on  the  GMAP  and  PDDI  extensions  software.  This  presentation 
reviewed  the  original  PDDI  software  nonqxnents  wrpliriTipd  the  enhancements  needed  to 
support  the  GMAP  interface  architecture.  These  enhancements  were  then  presented  in  more 
detail.  They  were:  Schema  Manager,  N/VI,  and  System  Translators. 

At  the  end  of  the  fourth  aession,  the  meeting  was  divided  into  two  groups.  The  IRB 
members  adjourned  to  an  executive  session  srith  Pratt  &  Whitney  and  the  USAF  to  discuss 
GMAP  status  and  technical  direction  in  mote  detail.  The  observers  were  provided  an  opportxinity 
to  join  one  of  three  round  table  discussions  on  the  topics  presented  in  sessions  2,  3,  and  4. 

Session  five  was  devoted  to  presentations  on  lire  GMAP  application  interfaces  and  planned 
demonstrations.  The  first  presentation  in  this  session  reviewed  the  contract  commitment  for 
demonstration,  explained  where  in  the  life-cycle  these  demonstrations  fell,  and  also  outlined  the 
GMAP  PDD  usage  for  each  of  the  demonstrations.  This  was  followed  by  a  briefing  on  each  of  the 
planned  demonstrations.  The  last  presentation  in  this  session  reviewed  the  demonstrations  being 
conducted  on  the  PDDI  extension  contract. 

The  last  technical  session  included  a  review  of  the  PDDI  extension  project  organization  as 
well  as  the  PDDI  extension  membership.  The  presentation  focused  on  the  efforts  being  devoted 
to  PDES/Standard  for  the  Exchange  of  Product  Model  Data  (STEP)  support,  electronic 
definition,  PDD  modeler,  and  cog^guration  support. 

3.1.1. 4.3.4  Fourth  IRB  Meeting 

The  fourth  GMAP  IRB  meeting  was  held  at  the  Holiday  Inn  near  Bradley  Airport  in 
Connecticut  3  and  4  December  1987.  Structured  as  a  highly  interactive  workshop,  the  meeting 
dealt  with  the  issues  and  concerns  of  the  minimum  requirements  of  a  product  modeler. 
Approximately  40  people  were  in  attendance  at  this  meeting  which  was  restricted  to  IRB 
members  and  a  few  invited  guests. 

Introductory  oonunente  were  given  by  Linda  Phillips,  Pratt  it  Whitney  GMAP  Program 
Integrator.  Ms.  Phillips  welcomed  everyone  and  reviewed  the  agenda  for  the  workshop.  She  also 
presented  a  review  of  the  status  of  the  project  and  described  the  technical  progress  to  date. 
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Mr.  Richard  Lopatka,  Pratt  &  Whitney  GMAP  Program  Manager,  followed  with 
welcoming  remarks.  Mr.  Lopatka  spoke  of  the  motivators  for  thi"  meeting.  He  stated  that  the 
general  purpose  of  the  meeting  was  to  discuss  the  various  issues  regarding  a  product  modeler. 
Next,  Mr.  Lopatka  discxissed  the  Technical  Issues  in  Product  Data  Transfer.  These  issues  fell 
into  four  major  categories: 

•  Technology  Shortfall 

•  Dynamic  Environment 

•  Integrated  .^proach 

•  Special  DoD  Requirements. 

A  more  in-depth  discussion  of  these  issues  is  presented  in  Appendix  C.  This  presentation 
was  well  received  by  those  in  attendance  and  helped  to  set  the  tone  for  the  remainder  of  the 
workshop. 

Next,  the  IRB  workshop  Chairman,  Mr.  Edward  Schumaker,  reviewed  the  primary  reasons 
for  the  workshop: 

•  Feedback  from  the  last  IRB  meeting  concerning  the  Minimum  Requirements 
for  a  Product  Modeler  document 

•  PDDI  and  GMAP  technology  development  efforts  had  shown  the  need  for 
some  sort  of  a  Product  Modeler  to  generate  the  necessary  models 

•  That,  in  the  future,  PDES  implementations  will  need  some  method  of  getting 
data  into  the  product  database. 

Mr.  Schumaker  then  reviewed  the  structure  and  breakout  of  the  discussion  groups,  the 
questions  for  discussion,  and  assigned  session  leaders.  Everyone  in  attendance  was  assigned  to 
one  of  the  groups. 

The  remainder  of  the  meeting  revolved  around  the  session  workshops  and  reports  of  the 
groups  back  to  the  total  workshop.  As  a  result  of  this  meeting,  the  following  action  items 
resulted: 

•  At  the  next  IRB  Meeting,  the  GMAP  team  would  present  a  summary  of  the 
discussion  of  this  workshop.  Also,  plans  for  revising  the  Minimiun  Require¬ 
ments  of  a  Product  Modeler  would  be  required. 

•  Discussion  of  a  Product  Modeler  and  the  Minimum  Requirements  Document 
would  be  included  in  the  GMAP  end  of  contract  videos. 

•  Pratt  &  Whitney  would  compare  the  Product  Modeler  requirements  to  the 
Navy  CAD/CAM  specification. 

The  feedback  from  those  in  attendance  indicated  that  the  workshop  was  very  successful. 
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3.1.1. 4.3.5  Fifth  IRB  Meeting 

The  fifth  IRB  meeting  was  held  on  1  and  2  March  1988,  in  St  Louis,  Missouri.  Seventy- 
eight  people  registered  for  the  meeting. 

The  primary  purpose  of  this  meeting  was  to  provide  an  end-of-contract  debriefing  on  the 
PDDI  extension  program  that  ended  December  1987.  Videotapes  of  the  PDDI  extension 
demonstrations  were  shown  on  both  days  before  and  after  formal  presentations.  The  meeting 
also  included  an  update  on  the  GMAP  program. 

Ms.  Linda  Phillips  opened  the  IRB  meeting  with  a  welcome  and  a  review  of  the  two  day 
agenda.  Chairman  George  Hess  followed  by  congratulating  the  Air  Force  and  MCAIR  on  the 
success  of  the  PDDI  program. 

Mr.  Gerald  Shumaker,  Area  Manager  of  the  Computer  Integrated  Manufactur- 
ing/Manufactiiring  Science  at  Wright  Patterson  Air  Force  Base,  spoke  next  about  the  Materials 
Lab  perspective  on  PDES. 

The  PDDI  and  PDDI  extension  programs  were  then  reviewed.  The  objectives  of  PDDI 
program  were  to:  functionally  replace  the  engineering  drawing,  provide  an  interface  between 
Engineering  and  Manufactxuing,  cmd  demonstrate  the  transfer  of  PDD  between  dissimilar 
CAD/CAM  systems.  The  PDDI  extension  program  extended  the  PDDI  schema  to  include 
electronic  components,  studied  product  modeler  development,  demonstrated  a  two-way  inter¬ 
change  of  two  PDD  models  with  a  subcontractor,  and  developed  a  PDDI  software  configuration 
control  system. 

Also,  an  overview  of  the  PDDI  and  GMAP  digital  exchange  environment  was  provided  by 
MCAIR.  It  focused  on  the  exchange  components  used  in  this  enviromnent,  the  system 
architecture,  and  model  creation. 

A  description  of  the  PDD  “modeler”  developed  at  MCAIR  was  also  presented.  This 
“modeler”  used  graphics  software  to  create,  manipulate  and  interrogate  working  form  models. 
The  “modeler”  used  the  geometry  created  in  MCAlR’s  CAD/CAM  system,  model  access 
software,  and  data  dictionary  entity  definitions.  A  key  requirement  of  the  PDD  modeler  was  that 
it  perform  with  any  entity  that  may  be  defined  without  having  to  modify  the  software  for  each 
entity  addition  or  change.  This  was  accomplished  via  the  data  dictionary.  PDD  models  used  for 
the  demonstrations  of  the  PDDI  extension  contract  were  a  machined  rib,  composite  rib,  B1  spar 
clip,  printed  wiring  assembly,  and  a  printed  wiring  board. 

Next,  the  demonstration  of  the  digital  exchange-customer  demonstration  with  MCAIR  and 
the  Sacramento  Air  Logistics  Center  (SM-ALC)  was  reviewed.  In  this  demonstration,  models  of 
a  3-axis  machined  rib  and  a  composite  rib,  designed  and  built  by  MCAIR,  were  communicated  to 
SM-ALC  using  the  MAS  and  system  translator.  SM-ALC,  in  turn,  utilized  the  system  translator, 
the  MAS,  and  a  Unigraphics  translator  to  place  the  models  in  the  Unigraphics  data  base. 
SM-ALC  then  manufactured  the  3-axis  machined  rib  and  sent  it  to  MCAIR  for  inspection. 

An  overview  of  the  digital  exchange-subcontractor  demonstration  was  also  presented. 
Partners  in  this  demonstration  were  MCAIR,  LTV  Aircraft  Products  Group,  and  Automation 
Technology  Products  (ATP).  MCAIR  designed  tmd  modeled  a  machined  rib  that  was  then 
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manufactured  by  LTV.  LTV  designed  and  modeled  a  Bl  spar  clip  that,  in  turn,  was 
manufactured  by  MCAIR.  ATP  developed  the  native  system  translator  that  imported  and 
exported  the  3  axis  rib  and  the  Bl  spar  clip  models. 

The  PDDI  electronic  component  phase  of  the  PDDI  extension  program  focused  on 
broadening  the  PDDI  schema  to  include  printed  wiring  assemblies  and  printed  wiring  boards. 
Partners  in  this  demonstration  were  McDonnell  Douglas  Astronautics  (MDAC)  and  Westing- 
house.  This  demonstration  determined  the  data  needed  to  define  a  printed  wiring  assembly  and 
printed  wiring  board,  expanded  the  PDDI  conceptual  schema  to  capture  printed  wiring  assembly 
and  printed  wiring  boards,  defined  a  sample  printed  wiring  board/assembly,  created  a  working 
form  model,  and  finally,  compared  existing  and  emerging  neutral  data  formats  for  electronics 
with  the  PDDI  schema. 

The  objectives  of  the  PDDI  software  configuration  control  system  (SCC)  were  to  control 
and  track  the  distribution  of  PDDI  software  to  and  fiom  authorized  development  contractors  and 
authorizec.  PDDI  users  from  central  locations.  The  SCC  is  IBM-PC  bas^  and  uses  dBASEIII 
which  is  a  '  <!lational  database.  A  demonstration  of  the  system  was  given  after  the  presentation. 

An  IRB  ecutive  session  was  held  to  review  the  presentations  given  on  the  1st  day.  The 
members  were  g.  erally  pleased  with  the  results  of  the  PDDI  extension  contract  and  strongly 
recommended  that  results  of  the  project  be  thoroughly  documented.  They  asked  that  the  results 
of  the  3  axis  machined  rib  be  documented  so  that  others  could  benefit  from  MCAIR’s  experience. 

Ms.  Linda  Phillips  presented  plans  for  the  GMAP  video  tapes,  including  the  IRB’s  review 
of  the  draft  scripts  for  the  videos.  The  IRB  agreed  to  review  a  pre-release  of  the  video  scripts. 

The  second  day  of  the  meeting  began  with  a  review  of  the  agenda  by  Ms.  Phillips.  A 
presentation  of  current  PDES  support  by  MCAIR  and  D.  Appleton  Company  (DACOM)  was 
given.  MCAIR  and  Pratt  &  Whitney  personnel  sijpported  information  models  for  the  PDES 
community.  The  PDDI  exchange  format  led  to  the  development  of  the  PDES  exchange  file 
format.  Similarly,  the  PDDI  data  specification  language  led  to  the  development  of  EXPRESS. 
The  IGES/PDES  prototype  translator,  the  EXPRESS  language  and  the  GMAP/PDDI  schema 
manager  were  reviewed  by  MCAIR. 

Pratt  &  Whitney  discussed  the  relationship  of  the  PDDI  and  PDDI  extension  programs  to 
the  GMAP  project.  A  roadmap  document  describing  and  cataloging  the  deliverables  of  the  three 
projects  was  distributed. 

Plans  for  revising  the  “Minimum  Requirements  for  a  Product  Modeler”  document  were 
also  presented  by  Pratt  &  Whitney.  The  document  would  be  renamed  to  “Functional 
Requirements  of  a  Product  Modeler”.  Pratt  &  Whitney  planned  to  send  out  an  RFP  that  would 
establish  a  team  of  experts  from  a  variety  of  discqilines  to  rewrite  the  document. 

3.1.1. 4.3.6  Sixth  IRB  Meeting 

The  sixth  IRB  meeting  was  held  15  and  16  September  at  United  Technologies  Conference 
Facilities  in  Orlando,  Florida.  The  primary  objective  of  this  meeting  was  to  provide  an  executive 
review  on  the  results  and  lessons  learned  in  GMAP.  Invited  attendees  included  GMAP  IRB 
memhers.  Air  Force  GMAP  Program  Management  personnel,  and  key  members  of  the  GMAP 
technical  task  groups.  Approximately  40  people  attended  the  meeting. 
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The  meeting  was  divided  into  five  sections.  Session  one  featured  the  opening  remarks  and  a 
brief  overview  of  the  GMAP  objectives  and  current  program  status  by  Ms.  Linda  Phillips,  Pratt 
&  Whitney’s  GMAP  Program  Integrator. 

Session  two  was  devoted  to  viewing  the  GMAP  demonstration  videotapes.  The  session 
began  with  an  overview  of  all  the  GMAP  tapes  and  an  explanation  of  Uie  underl3ring  objectives 
and  audience  at  which  the  tapes  were  aimed.  The  first  videotape  shown  was  the  Technical 
Summary.  This  tape  was  made  by  employing  an  interview  style  with  key  members  of  the  GMAP 
technical  team  to  provide  a  summary  of  the  work  accomplished  <m  GMAP.  The  next  two 
videotapes  contain^  the  life  cycle  demonstrations  for  the  blade  and  disk.  Prior  to  showing  these 
videos,  a  brief  introduction  was  given,  one  for  the  Blade  and  one  for  the  Disk.  A  short  discussion 
period  followed  each  of  the  tapes.  The  fourth  videotape  consisted  of  demonstrations  involving  a 
plumbing  attachment  boss  on  an  engine  case.  This  deiQonsfvation  was  conducted  to  provide 
evidence  that  GMAP  concepts  can  be  applied  t&peaOb'ABA.  toe  more  typical  of  industries  outside 
of  aerospace. 

The  discussions  that  followed  each  of  these  tapes  provided  some  excellent  suggestions  on 
how  to  make  better  use  of  the  GMAP  videot^es.  A  few  suggestions  were  made  on  possible 
modifications  to  the  tapes  themselves. 

During  the  second  session,  video  ]>fnsonneI  worked  with  selected  members  of  the  IRB  to 
film  interview  segments  for  the  executive  overview  tf|pe.  This  tape  was  produced  to  provide  a 
management  perspective  of  the  GMAP  efforts  and  fiie  future  impact  on  industry.  Session  two 
also  consisted  of  several  round  table  groups  that  allowed  attendees  to  view  the  videotapes  a 
second  time  and  enter  into  more  in-depth  discussion  with  GMAP  personn^  concerning  results 
and  lessons  learned. 

The  third  session  presented  an  opportunity  for  Air  Force  representatives  to  voice  their 
opinions  of  the  GMAP  work.  Plaques  of  appreciation  were  given  the  Air  Force  to  the  IRB 
members  for  their  efforts.  The  Air  Force  also  opened  the  floor  for  discussion  concerning  plans 
beyond  GMAP.  They  also  wanted  to  know  the  IRB’s  ideas  on  how  GMAP  could  best  be 
transitioned  into  industry  and  the  Department  of  Defense  (DoD). 

The  IRB  expressed  the  opinion  that  the  Air  Force  should  sponsor  the  application  of  GMAP 
software  to  some  of  the  parts  that  will  be  used  in  the  Advanced  Tactical  Fighter  (ATF).  There 
should  be  some  attention  given  to  assemblies  and  assembly  modeling.  Interfaces  to  other 
databases  should  also  be  built.  The  feedback  loop,  and  iterative  design  should  also  be  exanoned 
along  with  the  whole  area  of  computer  hardware  and  processing  time,  such  as  storage  and  the 
time  needed  to  access  part  files.  Configuration  Management;  what  is  released,  to  whom,  when, 
and  so  on,  is  also  important. 

The  fourth  session  focused  on  plans  for  the  end-of-contract  Industry  Debriefing.  The  IRB 
members  were  questioned  as  to  what  audience  should  be  captured,  durathbai  of  the  meeting,  and 
what  topics  and  degree  of  technical  depth  should  the  presented.  Comments  and  suggestions 
expressed  by  the  IRB  were  reviewed  and  incorporated  as  appropriate  into  plans  for  the 
Debriefing. 

During  the  fifth  session,  GMAP  personnel  reviewed  plans  for  the  «dnd  down  of  the  contract 
and  the  8  month  extension  that  will  permit  the  team  to  complete  the  supplier  portion  of  the 
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Casting  Tooling  demonstration  and  the  rewrite  of  the  “Minimum  Requirements  for  a  Product 
Modeler”  report.  Also  included  in  this  extension  will  be  a  debriefing  for  the  Repair  Technology 
(REPTECH)  organization  and  participation  in  CIM  Industry  Days. 

3.1. 1.9  Software  Quality  Assurance  (SQA) 

Pratt  &  Whitney  prepared  a  preliminary  Software  Quality  Assurance  Plan  to  ensure  that 
computer  software  developed  during  the  program  conforms  to  quality  requirements  in  a  cost 
effective  manner.  The  Plan  applied  to  all  program  software  deliverable  to  the  Air  Force.  The 
following  paragraphs  summarize  its  coverage. 

3.1.1  5.1  Establishment  of  SQA  Authority 

Pratt  &  Whitney’s  authority  for  Information  Systems  to  provide  overall  administration  of 
SQA  is  defined  in  our  Quality  Manual.  In  addition,  each  subcontractor  delivering  GMAP 
software  developed  a  SQA  plan  that  adheres  to  the  contents  of  the  Plan. 

3.1. 1.5.2  Configuration  Management 

Procedures  were  developed  to  control  configuration  management  and  bbraiy  controls.  The 
personnel  responsible  for  developing  a  specific  subsystem  were  also  responsible  for  controlling 
a  id  maintaining  the  associated  source  libraries.  They  were  also  responsible  for  delivering  the 
correct  version  of  the  source  and  object  code  to  the  subcontractor.  The  SQA  organizations 
audited  the  controlled  software  libraries.  Provisions  for  off-site  storage,  recovery  procedures,  and 
purging  were  also  covered  in  this  section  of  the  document. 

3.1.1.5.3  Program  Documentation 

Procedures  governing  program  documentation  were  developed.  Program  notebooks  or  file 
folders  contained  the  following  components:  introduction,  requirements,  detailed  design,  test 
criteria,  and  programming  changes.  Specification  compliance  and  procedures  relating  to  user 
guides  were  also  included. 

3.1. 1.5.4  Corrective  Action 

Corrective  action  procedures  were  established  to  provide: 

•  Identification/documentation  of  software  problems 

•  Analysis  of  problem  causes 

•  Adequacy  of  problem  resolution 

•  Authorization  to  implement  the  change 

•  validation/verification  of  the  change  implementation. 

3.1. 1.5.5  Testing 

Procedures  were  developed  to  control  testing  of  software.  The  SQA  organizations 
monitored  software  testing.  They  also  audited  test  documentation  and  rqx>rting  for  comple¬ 
teness,  adequacy,  and  conformance  to  requirements.  Additionally,  test  sufqwrt  software  were 
verified  to  comply  to  the  program  requirements  established  for  that  software. 
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3.1.1.5.6  Tools,  Techniques,  end  Methodologies 

Tools,  techniques  and  methodologies  used  by  the  project  were  identified.  Examples  include: 
automated  system  to  generate  charts  for  use  as  a  design  tool;  walkthroughs  conducted  to  verily 
codes,  etc. 


3.1. 1.5.7  Reviews  and  Audits 

Although,  Pratt  &  Whitney  was  responsible  for  coordinating  the  SQA  program,  all 
deliverable  software  under  the  GMAP  contract  was  developed  by  MCAIR  and  FIl.  ^th  of  these 
contractors  developed  preliminary  SQA  plans  supporting  Pratt  &  Whitn^’s  overall  plan.  Pratt 
&  Whitney  maintained  copies  of  these  plans  and  periodically  audited  contractor  adherence  to 
them. 

Reviews  and  audits  were  conducted  to  determine  the  level  of  compliance  to  the  SQA 
requiremei.  <«.  Subcontractors  audited  areas  such  as  systems  requirements  review  and  systems 
specification  •eview. 

3.1.2  Identify  Gvometric  Modeling  Application  Interface  Needs  (Subtask  1.2) 

The  IDEFO  functional  modeling  efforts  resulted  in  approximately  100  candidate  functional 
applications  being  identified  for  the  IDEFlX  information  modeling  methodology.  These 
included: 

•  Graphic  systems 

•  Geometry  processors 

•  Numerical/control  (N/C)  toolpath  utilities 

•  Cooling  hole  laser  drilling  programs 

•  Coordinate  measuring  machines  program  generators 

•  Finite  element  stress  programs 

•  Tolerance  chart  programs. 

3.1 .2.1  Establish  Information  Needs 

Criteria  were  established  to  aid  the  scoping  of  the  numerous  functional  applications  down 
to  those  to  be  modeled  for  information  needs.  Re\dew  and  discussion  of  these  criteria  among 
experts  from  the  functional  areas,  UTRC  IDEFO  modelers,  and  other  GMAP  personnel  led  to  the 
development  of  five  basic  questions. 

1.  How  important  is  this  application  to  the  full  life-cycle  coverage  of  turbine 
blades  and  disks? 

2.  What  is  the  breadth  of  the  functional  application  in  the  full  life-cycle 
coverage? 

3.  What  is  the  depth  of  the  fimcrional  application  in  terms  of  producing  or 
consuming  PDD? 
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4.  If  this  application  is  si4)porte<l,  how  much  enhancement  or  advancement  will 
be  enabled? 

6.  Does  the  iq>plication  meet  the  requirements  of  the  GMAP  contract? 

As  a  result,  the  following  16  key  functional  iq>plication  areas  were  selected  for  evaluation  of 
information,  or  data,  needs. 

•  Preliminary  Engineering  Design 

•  Detailed  Blade  and  Disk  Design  and  Analysis 

•  Final  Blade  and  Disk  Design  and  Analysis 

•  Detailed  Engineering  Specifications 

•  Casting  Process  Planning 

•  N/C  Programming  for  Casting  Molds  and  Dies 

•  Categorize  and  Review  Parts/Processes 

•  General  Process  Planning 

•  Tool  Design 

•  N/C  Programming  for  Disk  Machining 

•  N/C  Programming  for  Laser  Hole  DrUling 

•  Quality  Requirements  Engineering 

•  Programming  Automated  Inspection  Devices 

•  Provide  Technical  Support 

•  IBIS 

.  RFC. 

Each  area  was  investigated  for  mechanisms,  both  computerized  and  noncomputerized,  that 
were  creators  or  users  of  PDD.  Collectively,  the  applications  studied  represented  a  comprehen¬ 
sive  cross  section  of  technical  disciplines  common  to  the  design,  manufacture,  and  support  of 
complex  mechanical  products. 

The  first  step  in  the  investigation  was  to  document  the  current  environment,  focusing  on 
the  functional  interrelationships  of  the  areas  involved.  This  step  established  the  as-is  system. 

Personnel  in  appropriate  functional  areas  were  interviewed  to  identify  and  collect  source 
material,  to  understand  the  flow  of  PDD  through  the  life  cycle,  and  to  determine  user  interface 
and  data  needs,  and  benefits.  Next,  this  information  was  analyzed  to  determine  the  information 
needs  of  the  functional  areas  investigated.  In  addition,  information  compiled  allowed  the 
investigators  to  establish  opportunities  for  improvements  to  the  overall  systems.  This  step 
established  the  to-be  system. 

For  descriptions  of  the  application  areas  and  discussions  of  the  as-is  and  to-be  conditions, 
readers  may  consult  the  GMAP  Needs  Analysis  Document  (NAD),  Cl  NAD560240001U.  The 
PDD  needs  for  each  of  these  areas  are  summarized  below. 

3.1.2.1.1  Preliminary  Engineering  Design 

Investigation  determined  that  there  were  no  PDD-related  needs  this  early  in  the  design 
process.  Most  of  the  data  at  this  point  are  considered  product  data  because  product  shape  has  not 
yet  been  determined.  Feedback  capability  of  PDD,  however,  woiild  be  useful. 
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3.1.2.1.2  Detailed  Blade  and  Disk  Design  and  Analysis 

Investigation  identified  these  following  PDD-related  needs  for  thi«  function. 

•  Internal  geometry  of  ribs,  trip  ^r4>8i  pedestals,  and  other  internal  cooling 
features,  and  all  wall  thickne^ca  were  necessary. 

•  The  ability  to  stack  and  fair  both  internal  and  external  geometry,  thus 
creating  a  3-D  airfoil  shape,  was  needed. 

•  Storage  of  the  complete  blade  and  disk  geometry  in  a  form  that  accommodates 
original  definitions  and  working  representations  of  geometry  was  required. 

•  Three-dimensional,  finite-element  modeling  was  required,  as  was  data 
storage,  data  management,  and  data  security  system  to  allow  rapid  communi¬ 
cation  of  geometry  and  other  related  information. 

3.1 .2.1.3  Final  Blade  and  Disk  Design  and  Analysis 

The  following  PDD-related  needs  were  identified  for  this  function. 

•  Airfoil  external  shape,  airfoil  internal  feature  definition,  and  the  ability  to 
create  or  extrapolate  additional  extended  airfoil  sections  for  manufacturing 
were  required. 

•  The  ability  to  integrate  the  preceding  information  into  existing  computer  files 
was  needed. 

•  The  capability  of  building  cooled  airfoils  electronically  (including  the  ability 
to  add,  delete,  and  modify  functional  subsets  of  the  model)  was  also  needed 

•  Cooling  hole  descriptions  for  shaped  and  circular  holes  were  required. 

•  Tolerances  associated  to  geometry  were  needed. 

•  Assembly  information  was  needed. 

•  Pratt  &  Whitney  specifications  were  necessary. 

•  Notes  and  administrative  data  were  needed. 

3.1.2.1.4  Detailed  Engineering  Specificatione 

The  following  PDD-related  needs  for  this  function  were  identified. 

•  The  ability  to  represent  the  complete  blade  and  disk  geometric  definition  via 
mathematical  di^ription  needed  to  be  provided.  Rxisting  methods  required 
illogical  human  interpretation  (for  example,  “fair  smoothly"). 
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- 

• 

The  addition  of  tolerance  and  datum  information  (and  nongeometric  data 
such  as  notes,  finish,  and  approvals)  was  required. 

- 

• 

The  computer  data  base  needed  to  correlate  PDD  with  conventional  drawing 
output  to  satisfy  the  human  need  for  visualization  of  requirements. 

• 

PDD  needed  to  include  “source  data”  to  construct  evaluated  models,  rather 
than  be  limited  to  the  evaluated  models  alone. 

3.1.2.1.5 

Casting  Process  Planning 

The  following  PDD-related  needs  for  this  function  were  identified. 

• 

A  complete  and  accurate  3-D  model  was  needed  to  generate  the  wide  variety 
of  surfaces  and  geometric  representations  required  to  support  finite-element 
casting  simulations  and  the  development  of  tooling  requirements. 

• 

t.  mport  of  constructive  reference  geometry  was  needed  to  support  dimension¬ 
al  c  djustments. 

• 

Intellige,it  support  of  gage  points,  datums,  reference  lines,  and  airfoil 
dimensioning  and  tolerancing  systems  was  needed. 

3.1.2.1.6 

N/C  Programming  for  Casting  Molding  and  Dies 

• 

The  following  PDD-related  needs  for  this  function  were  identified. 

There  was  a  need  for  an  accurate  3-D  model  to  represent  geometry  in  its 
simplest,  most  complete  form  and  to  generate  different  surfaces  and  different 
mathematical  surface  representations. 

• 

There  was  a  need  to  standardize  the  mathematical  representation  of  complex 
splined  aerodynamic  surfaces  or  to  identify  a  compatible  common  denomina¬ 
tor  that  could  be  shared  and  used  between  different  systems.  This  would 
require  the  use  of  stable,  generally  usable  cubic  splines. 

• 

Explicit  definition  of  all  geometry  was  needed. 

• 

The  ability  to  support  reference  data  was  needed.  This  included  surface 
normals/tangents  and  definition  of  airfoil  inner  and  outer  contours  below  the 
root  and  beyond  the  tip. 

• 

The  ability  to  support  constructive  geometry  in  the  model  was  needed. 

• 

Also  needed  was  the  intelligent  support  of  gage  points,  datums,  reference 
lines,  and  airfoil  dimensioning  and  tolerancing  systems. 

• 

There  was  a  need  for  interactive  graphics  systems  to  st^port  surface 
motfifications  and  offsets  associated  with  nonlinear  casting  and  manufactur¬ 
ing  factors  such  as  ceramic  shrinkage  and  EDM  overbum. 

• 
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3.1 .2.1. 7  Categorize  and  Review  Parts/Proceases 

The  following  PDD-related  need  for  this  function  was  identified. 

•  Automatic  GT  code  generation  required  a  computer  model  that  ezplicitly 
identified  dimensions,  tolerances,  features,  topological  groups,  materials,  and 
process  requirements  such  as  shot  peening  and  joining. 

3.1.2.1.8  General  Process  Planning 

The  following  PDD-related  needs  for  this  function  were  identified. 

•  A  complete,  integrated  3-D  part  model  was  required  to  support  the  computer¬ 
ized  process  planning  environment. 

•  Constructive  geometry  was  required  by  the  GENCAPP  system. 

•  Support  of  dimensions,  tolerances,  gage  points,  and  datums  was  required  for 
determining  sequence  of  cuts  and  fixturing  requirements.  This  included 
associative  geometric  tolerances. 

•  Intelligent  support  of  notes  was  required  to  support  planning  for  chemical  and 
metallurgical  processes  such  as  coating,  heat  treat,  and  shot  peening.  This 
included  surface  finish  and  material  properties. 

•  Features  were  a  key  to  automating  Process  Planning  because  individual 
processes  make  features. 

•  Support  of  in-process  part  geometry  and  tooling  geometry  was  required  for 
Process  Planning  and  for  passing  requirements  to  Tool  Design  and  N/C 
Programming. 

3.1.2.1.9  Too!  Design 

The  following  PDD-related  needs  for  this  function  were  identified. 

•  A  complete,  integrated  3-D  PDD  model  with  dimensions,  tolerances,  and  gage 
points  was  needed. 

•  Accurate  representation  of  all  geometry,  including  airfoil  geometry,  was 
needed. 

•  The  ability  to  support  various  geometric  representations  such  as  wireframe, 
surface,  and  constructive  geometries,  was  noeded. 

•  Feature  identification  was  necessary. 
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•  The  ability  to  support  complex  airfoil  surfaces  and  internal  cooling  passages 
was  needed. 

•  The  support  of  intermediate  manufacturing  and  tooling  geometries,  was 
needed. 

3.1.2.1.10  N/C  Programming  for  Disk  Machining 

The  following  PDD-related  needs  for  this  function  were  identified 

•  Complete,  integrated  3-D  geometric  models  that  support  fi.aal  product, 
intermediate  manufacturing  part  shapes,  and  tooling  were  needed. 

•  Multiple-part  geometry  representation  capability  was  required  to  support 
different  N/C  applications.  For  example,  2-D  profiles  were  required  for 
turning,  while  3-D  models  are  required  for  machining. 

•  The  ability  to  support  features  and  patterns  such  as  bolt  bole  patterns  was 
needed.  This  would  enable  automatic  generation  of  pocketing  sequences, 
roughing  and  profiling  sequences,  and  bolt-hole  drilling  sequences. 

•  Support  of  constructive  geometry,  datums  and  dimensions  for  situations  such 
as  radius  runout  and  sharp  edge  dimensions  were  also  needed  to  define 
geometry  for  N/C  programming. 

3.1.2.1.11  N/C  Programming  for  Laser  Hole  Drilling 

The  following  PDD-related  needs  for  this  function  were  identified. 

•  Laser  hole  drilling  required  definition  of  hole  patterns  using  constructive 
geometry  based  on  the  use  of  datum  planes  and  gage  points. 

•  Interactive  graphics  programming  required  a  3-D  part  model. 

3.1.2.1.12  Quality  Requirements  Engineering 

The  following  PDD-related  needs  for  this  function  were  identified. 

•  Support  of  quality  assurance  data  sheet  information  as  part  of  process 
requirements  was  required. 

•  Types  and  sequences  of  inspections  were  required  to  be  identified. 

•  References  to  specifications  and  standards  related  to  specific  features  and 
processes  needed  to  be  siqiported. 

•  The  ability  to  identify  features,  dimensions,  tolerances,  and  inspection 
requirements  as  critical  and  major  characteristics  was  needed. 
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3.1.2.1.13  Programming  Automated  Inspection  Devices 

The  following  PDD-related  needs  for  this  function  were  identified. 

•  A  complete,  3-D  electronic  PDD  model,  which  intelligently  siq>ports  features, 
dimensions,  tolerances,  and  notes,  was  needed. 

•  Notes  must  be  supported  intelligently  to  support  airflow,  nondestructive 
testing,  and  dimensional  inspection  requirements  such  as  dishing. 

•  The  use  of  traceability  numbers  was  needed  for  nonserialized  parts  to  support 
automated  inspection  applications,  particularly  airflow  inspection.  This 
allowed  the  data  to  be  used  for  trending  and  engineering  evaluation. 

•  The  intelligent  support  of  gage  points,  datums,  and  reference  lines  used  by 
manufacturing  and  inspection  was  required. 

•  A.  ^il  dimensioning  and  tolerancing  requirements  such  as  stacking  lines, 
airlc  '^  sections,  gage  points,  and  features,  was  needed. 

•  Intermeai?te  manufacturing  geometries  and  processing  requirements  were 
also  needed  to  support  in-line  inspection. 

3  1.2.1.14  Provide  Technicaf  Support 

The  following  PDD-related  needs  for  this  function  were  identified. 

•  A  complete  PDD  model  was  needed  by  Product  Support. 

•  Support  of  the  tooling  geometry  was  required  in  the  design  of  the  ground- 
support  equipment. 

•  Accurate  representation  of  all  geometry  was  required. 

•  Various  geometric  representations,  such  as  wireframes,  surface,  and  construc¬ 
tive  geometries,  were  needed. 

•  Required  inspection  and  maintenance  sequences  needed  to  be  identified. 

•  References  to  specifications  and  standards  related  to  specific  processes 
needed  to  be  supported. 

3.1.2.1.15  IBIS 

The  following  PDD-related  needs  for  this  hinction  were  identified. 

•  A  complete  bi-cubic  representation  of  the  blade  was  needed. 

•  Product  support  information  on  the  technical  order  (the  blade  areas  and  the 
serviceable/repairable  limits  for  those  areas)  was  also  required. 
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3.1.2.1.16  RFC 

The  following  PDD-related  needs  were  determined  for  this  function. 

•  A  mechanism  was  needed  to  define  information  associated  with  a  specific 
period  in  the  life  cycle  of  a  part. 

•  A  mechanism  was  needed  to  specify  required  administrative  data,  such  as 
revision  information  and  material  type. 

•  3-D  geometry  and  topology  capable  of  defining  areas  targeted  for  inspection 
were  required. 

•  Mechanisms  to  specify  a  set  of  parameters  that  indicate  the  maximum 
serviceable  and  repairable  limits  of  surface  and  internal  flaws  in  various 
orientations  were  required. 

3.1. 2.2  Derive  and  Analyze  GMAP  Needs 

The  PDD  needs  for  each  of  the  16  applications  were  converted  into  specific  types  of  data 
that  would  be  needed  across  a  broad  spectrum  of  industry.  This  resulted  in  six  classes  of  data: 
Geometry,  Topology,  Form  Features,  Tolerances,  Nonshape  and  Notes,  and  Administrative  and 
Assembly.  As  a  result  of  the  DDEFlX  process,  a  ner^  data  class,  “Shape’,  was  added.  The  Shape 
data  class  primarily  integrates  geometric  and  nongeometric  data.  The  Topology  data  class 
became  one  of  three  subclasses  of  Shape.  The  Form  Features  data  class  was  incorporated  into  the 
Shape  subclasses. 

The  generic  data  needs  of  each  class  are  tabulated  on  the  following  pages.  For  a  more 
complete  description,  6Llong  with  associated  benefits  of  the  data  needed,  refer  to  the  Needs 
Analysis  Document  (Cl  NAD560240001U). 

3.1. 2.2.1  Geometry  Data  Needs 

The  Geometry  data  class  represents  shape  information  of  complex  mechanical  parts 
concisely  and  unambiguously.  This  class  supports  the  underlying  geometry  required  for  other 
classes  such  as  topology,  tolerances,  features,  shape,  and  nonsbape  data.  The  entities  in  this  class 
support  the  geometry  found  in  the  life  cycle  activities  of  turbine  blades  and  disks.  Therefore,  the 
complexity  of  these  parts  and  of  their  life  cycle  gives  GMAP  a  broad  scope,  but  allows  the 
implementation  of  GMAP  schema  to  a  wide  variety  of  parts. 

The  GMAP  approach  to  geometry  is  to  include  the  smallest  set  of  entities  needed  in  support 
of  life  cycle  activities,  and  to  support  geometry  common  to  most  CAD/CAM  systems.  Unlike  the 
other  classes,  geometry  is  very  hierarchical.  There  are  multiple  ways  to  represent  the  same  thing, 
and  these  multiple  representations  are  used  throughout  the  life  cycle  of  many  parts,  not  only 
turbine  blades.  The  intent  is  to  eliminate  any  multiple  or  redundant  definitions  while 
maintaining  precision  and  conciseness  of  representations. 

The  (jeometiy  class  contains  points,  vectors,  matrices,  curves,  and  surfaces.  Geometric 
tolerancing  is  addressed  to  ensure  data  integrity.  The  ability  to  group  geometric  entities  and  to 
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name  them  is  also  included.  This  ability  can  be  used  in  many  ways:  to  st4>ply  a  means  of  grouping 
some  or  all  part  cross  sections,  or  to  group  ^metiy  that  defines  part-specific  features  not 
represented  as  a  form  feature.  Table  3-8  identifies  the  Geometry  data  needs. 


TABLE  3-8. 

GEOMETRY  DATA  NEEDS 


Dictinguiih  Between  2'D  and  3-D  Geometry 
Bounded  and  Uirbounded  Geometry 
Geometric  Grot^lng 

Minimum  Number  of  Curve  Representatiorts 
B-Splinea,  Polynomial  Splinea,  Conic  Curves 
Mirumal  Set  of  Surface  Representations 

laam/u 


3.1. 2.2.2  Shape  Data  Needs 

The  Shape  data  class  was  created  out  of  a  need  to  represent  intuitive  elements  of  product 
shape.  These  elements  show  no  regard  for  the  particular  geometric  modeling  method  used  to 
.*epresent  the  part.  This  data  class  has  three  major  subclasses:  Shape  Element,  Shape 
R  .‘presentation  Elements,  and  Geometric  Construction  Elements.  The  Form  Features  data  class 
was  incorporated  into  these  subclasses. 

3.1.2.2.2.1  Shape  Element 

Shape  Elements  are  used  to  represent  intuitive  aspects  of  part  shape  such  as  zones,  surface 
area,  faces,  etc.  This  concept  was  later  adopted  by  the  PDES  community.  Table  3-9  lists  the 
Shape  Elements  in  the  GMAP  schema. 


TABLE  3-9. 

SHAPE  ELEMENT  DATA  NEEDS 


Vertex 

Edge 

Surface  Area 
Zone 
Subface 

Face 

Form  Feature 
Object 

Simple  Object 
Compound  Object 
Feature  of  Size 
Conatructad  Geonretry 
awan/it 


Form  features  data  represented  a  significant  portion  of  the  Shape  Element  subclass  of 
Shape  Osta  needs.  Form  features  data  were  needed  to  identify  and  describe  geometric  design  and 
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processing  units  of  a  part.  This  is  because  a  great  deal  of  industrial  understanding  and  expression 
is  in  terms  of  form  features,  and  unit  processes  typically  produce  recognizable  form  features. 
Table  3-10  lists  the  Form  Features  data  needs. 


TABLE  3-10. 

FORM  FEATURE  DATA  NEEDS 


Fonn  Feature  Repreaentation 

Ahamata/Multipla  Feature  Repreaentationa 

Rcpieaentationa  of  Faaturaa  in  Different  Geometric  Modeb 

Generic  Feature  Modeling  Capabilitiea 

Feature  Modeling  Growth  Directions 

Conitructive  Feature  Representations 

Primitive  Constructive  Feature  Repreaentationa 

Edge  Modifier  Features 

Sweep  Representations  of  Features 

Section-defined  Features 

Replicate  Feature  Representations 

Feature  Patterns 

Nonconstructive  Feature  Representations 
Compound  Feature  Represenutiona 
Feature  Component  Location 
Feature  Function 

Feature  Limits _ 

R20«2/I9 


3.1.2.2.2.2  Geometric  Construction 

This  Geometric  Construction  subclass  of  the  Shape  data  class  provides  the  capability  to 
construct  geometric  entities  not  necessarily  on  the  part.  The  data  needs  of  this  subclass  were 
derived  from  the  needs  of  other  data  classes.  The  definition  of  these  needs  was  driven  primarily 
by  the  requirement  to  tolerance  off-part  geometry. 

3.1.2.2.2.3  Shape  Representation  (Topology) 

The  Topology  data  class  was  changed  to  the  Shape  Representation  subset  of  the  Shape  data 
class.  Shape  Representation  data  structures  geometric  information  into  a  complete,  unambiguous 
representation  of  nominal  part  shape.  Shape  Representation  relates  geometric  data,  establishing 
connections  and  bounds. 

The  PDDI  and  GMAP  walkthroughs  identified  four  types  of  solid  models  used  by 
applications  in  representing  the  GMAP  parts:  flat  pattern  or  linear  extrusion  representations, 
bo^es  of  revolution,  laminate  representations,  and  3-D  boundary  representations.  [Several  other 
useful  solid  model  types  could  be  added  to  this  list:  half  spaces,  constructive  solid  geometry,  3-D 
sheets,  locally  2-1/2-D  (linear  and  rotational  sweeps),  and  different  types  of  spatial  decomposi¬ 
tion  models  such  as  octrees.] 

For  GMAP,  Shape  Representation  data  consist  of  the  information  neceasauy  to  structure 
geometric  information  into  solid  models  of  the  four  types  identified  in  the  PDDI  and  GMAP  part 
walkthroughs.  Table  3-11  lists  the  Shape  Representation  data  needs. 


3-61 


Cl  FTR560240001U 
September  1989 


TABLE  3-11. 

SHAPE  REPRESENTATION  DATA  NEEDS 


Boundaiy  RqxeMnUtioni 

Body  of  Revolution  RepmenUtioni 

Flat  Pattern  (Elxtniaion)  Rapraaentationa 

Laminate  Rcpreaentationa _ 

aam/u 


3.1. 2.2.3  Tolerance  Data  Needs 

Tolerance  data  provide  entities  that  satisfy  the  need  to  express  the  allowable  variation  of 
products.  This  data  class,  originally  identified  in  the  PDDI  project,  provides  a  means  to  control 
dimensional  relationships  and  physical  characteristics  of  the  product. 

Dimensioning  and  tolerancing  is  fundamental  to  stating  engineering  design  requirements 
for  the  manufacture,  assembly,  and  support  of  jet  engine  components  and  is  most  commonly 
conveyed  on  engineering  drawings  of  one  form  or  another.  Variations  of  tolerancing  involve 
company-specific  dimensioning  and  tolerancing  conventions,  the  use  of  notes  (text)  to  state  or 
further  qualify  tolerancing  requirements,  the  use  of  engine  curating  cycle-dependent  tolerances 
in  logistics,  and  the  use  of  nondimensional  tolerances  such  as  airflow  limits.  These  forms  needed 
to  be  systematized. 

Tolerance  needs  addressed  in  the  Tolerance  data  class  are  concerned  with  the  meaning 
underl3nng  the  application  of  tolerances  to  a  geometric  model,  not  the  graphical  annotation  of  the 
same.  Graphical  manifestation  of  tolerances  on  an  engineering  drawing  is  an  application  that 
might  be  enabled  by  the  complete  product  definition  model.  Table  3-12  lists  the  Tolerance  data 
needs. 


TABLE  3-12. 

TOLERANCE  DATA  NEEDS 


Tolerancing  of  Intrinsic  Foaturee 

Tolerancing  of  Eztrinaic  Featun  Relationahipa 

Combined  Individual  Feature  and  Relationship  Tolerancing 

Tolerancce  Aeeociated  with  On-part  Dimeneiona 

Tolerances  Associated  with  Off-part  Dimeneiona 

Feature  Size  Tolerancing 

Location  Tolerancing 

Form  Tolerances 

Datums 

Projected  Tolerance  Zones 

Tolersnce  Function 

Material  Condition  Mo&fier 

Statistical  Process  Canltol  Tolerancas 

Airflow  Toterancee _ 

B3M03/lt 


3-62 


anu/i 


Cl  FTR560240001U 
September  1989 


3.1. 2.2.4  Nonshape  and  Notes  Data  Needs 

Nonshape  data  represents  and  supports  PDD  communicated  in  a  textual  manner.  This  data 
class  includes  information  typically  defined  by  alphanumeric  text  in  the  form  of  notes  and 
instructions.  A  diversity  of  textual  data  are  required  along  with  the  product  shape  definition  to 
completely  define  the  design  intent  of  a  product.  Though  the  shape  of  a  product  is  informative, 
an  explanation  of  that  “picture”  is  almost  always  required.  Furtibermore,  the  design  intent 
includes  information  that  is  simply  not  graphically  representable. 

The  nonshape  data  supports  drawing  notes  that  depict  a  ‘Vho,  what  when,  where,  and 
how”  concept.  The  “who”  may  be  a  statement  about  which  discipline  area  is  to  be  responsible  for 
the  nonshape  requirement,  such  as  inspection,  processing,  or  assembly.  The  “what”  is  the 
specific  statement  of  a  requirement  for  the  “where*,  such  as  “heat  treat  product”  or  “protective 
coat  this  area”.  “When”  embodies  any  concept  of  sequencing  or  precedence,  usuaUy  represented 
by  “before”  and  “after”  statements.  The  “where”  can  be  a  description  or  indication  of  where  on 
the  product  the  “what”  is  to  be  applied.  It  can  be  the  entire  product,  a  certain  area  of  the  product, 
or  certain  areas  of  the  product  to  be  excluded.  The  “how”  is  generally  a  reference  to  a 
specification  or  a  procedure  to  be  followed  in  producing  the  desired  result.  It  could  also  be  explicit 
instructions  included  on  the  drawing  itself.  Table  3-13  presents  the  Nonshape  data  needs. 


TABLE  3-13. 

NONSHAPE  DATA  NEEDS 


Discipline  Identification 
Computer-eensible  Information 
Nonshape  Text 
Cross-references 
Information  Priority 
Information  Sequence 
Nonshape  Processing  Information 
Treatment  Information 
Inspection  Information 
Assembly  Information 
General  Information 
Specification  References 
Materia]  References 
Derived  Data _ 

RMOl/li 


3.1. 2.2.5  Administrative  and  Assembiy  Data  Needs 

Administrative  and  Assembly  data  exist  in  several  forms  and  with  many  purposes. 
Administrative  data  are  usually  used  to  manage  an  enterprise.  Scheduling,  planning,  financial 
information,  and  certain  technical  data  such  as  data  exchange,  product  histoir,'  and  documenta¬ 
tion,  and  engineering  change  control  are  examples  of  Administrative  data. 

An  assembly  is  a  type  of  product  that  consists  of  two  or  more  product  components.  The 
product  components  are  joined  in  some  manner  to  produce  the  assembled  product.  Specific 
requirements  and  processes  apply  to  the  assembled  product  as  a  whole. 
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Assembly  data  convey  the  information  necessary  to  perform  the  function  or  process  by 
which  product  components  are  assembled  to  create  a  product.  These  data  include  administrative, 
shape,  geometry,  tolerance,  and  nonshape  information.  Many  of  these  requirements  are  not 
unique  to  assembly  products;  however,  the  needs  specific  to  assemblies  were  identified  during 
GMAP  walkthroughs. 

Critical  product  information  about  the  product  components  must  be  preserved  in  the 
assembly  product.  Relationships  between  the  product  components  are  established  in  the 
assembly.  The  product  component  properties  and  their  relevant  information  (shape,  nonshape, 
and  so  on)  must  be  preserved.  GMAP  addressed  the  first-level  assembly  of  blades  and  disks. 
Those  data  needs  are  presented  in  Table  3-14. 


TABLE  3-14. 

ADMINISTRATIVE  AND  ASSEMBLY  DATA  NEEDS 


Product 

Product  Vetaion 
Product  Component 

Association  of  Product  Version  and  Property 
Association  of  Product  Component  and  Property 
Approval 
Revision 

Product  Component  Orientation 

Tolerances 

Zones  in  Contact 

Noruhape  information  for  Asaembliea _ 

aaoaa/it 


3.1. 2.3  Review  Needs  Analysis 

A  thorough  discussion  of  the  identification  and  prioritization  of  the  GMAP  data  needs  was 
documented  in  the  Needs  Analysis  Document.  However,  key  findings  relating  to  these  needs  are 
summarized  below. 

•  For  complex  mechanical  components  PDD  must  include  all  concepts, 
attributes,  and  relationships  normally  communicated  from  design  throughout 
the  product  life  cycle.  The  engineering  drawing  and  related  technical 
documents  have  been  the  vehicles  historically  used  for  this  purpose.  For 
complex  mechanical  components,  both  shape  and  nonshape  information  and 
process  requirements  are  needed  to  fully  represent  a  component  (or  assem¬ 
bly). 

•  Applications  that  are  users  of  PDD,  as  opposed  to  those  that  are  producers  of 
PDD,  are  the  primary  beneficiaries  of  an  electronic  equivalent  of  the 
engineering  drawing. 

•  Computer-sensible  product  data  are  needed  for  applications  to  become  more 
automated  This  is  eq}ecially  true  for  most  applications  studied  in  manufac¬ 
turing,  inspection  and  logistics  support. 
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•  The  primary  responsibility  for  creating  FDD  lies  within  the  traditional 
mechanical  design  and  drafting  functions. 

•  Modelers  need  to  be  developed  to  create  the  required  FDD.  These  modelers 
may  actually  be  a  system  of  modelers  capable  of  providing  the  various  shape 
and  nonshape  data  required.  For  shape  data,  existing  geometric  and  solid 
modelers  are  capable  of  producing  the  geometry  and  topology  definitions 
required  by  some  using  applications,  but  not  without  problems  and  limita¬ 
tions. 

•  “In-process  geometry”  irr”«t  be  derivable  and  representable  from  FDD  for 
Frocess  Flanning,  N/C  Machining,  Automated  Inspection,  and  Tool  Design 
Applications. 

•  There  is  a  need  to  preserve  the  constructive  origins  of  shape  FDD  for  some 
applications. 

•  Although  solid  model  representation  of  shape  is  required  for  certain 
automated  applications,  not  all  applications  require  such  complete  informa¬ 
tion.  Some  applications  only  require  2-D  geometry.  Examples  are  applications 
dealing  with  Body  of  Revolution  (BOR),  or  turned,  parts  and  fiat  sheet-like 
parts. 

•  There  is  a  need  to  represent  geometry  in  multiple  forms  depending  upon  the 
using  application.  This  leads  to  the  requirement  for  standardized  representa¬ 
tions.  Evaluator  utilities  capable  of  converting  between  standard  forms  would 
be  very  useful. 

•  Features  are  a  key  to  applications  such  as  automated  process  planning,  since 
individual  piocesses  make  features. 

•  Tolerances,  datums,  and  their  relationships  to  part  shape  are  fundamental  to 
future  automated  applications.  Representations  of  tolerances  and  datums 
must  parallel  traditional  industry  standards  for  reasons  of  acceptability, 
useability,  traditional  practice,  and  so  on. 

•  Process  requirements  normally  conveyed  to  manufacturing  and  inspection  via 
notes  and  specification  invocation  on  engineering  drawings  must  continue  to 
be  conveyed  in  the  electronic  FDD  form.  The  bulk  of  of  this  information 
needs  to  be  represented  in  a  computer-sensible  form.  Other  information  is 
only  human  understandable  and  needs  to  be  conveyed  via  note  text  in  the 
FDD  model. 

•  The  information  communicated  from  mgineeriag  and  product  support  to 
logistics  support  is  done  so  using  the  technical  order.  This  information  is 
analogous  in  form  to  the  process  requirements  communicated  from  engineer¬ 
ing  to  manufacturing.  Provisions  for  incorporating  these  data  in  the  full  FDD 
model  are  essential. 
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•  Administrative  information  pertaining  to  the  control  and  management  of  the 
PDD  needs  to  be  included  with  the  technical  PDD. 

•  Assembly  PDD  is  normally  conveyed  using  layout  and  assembly  drawings. 
Information  contained  on  these  traditional  documents  falls  into  categories 
similar  to  those  required  for  component  PDD.  These  are  geometry,  topology, 
features,  tolerances,  nonshfgpe  and  notes  (process  requirements  being  assem¬ 
bly  requirements  in  this  case),  and  administrative. 

3.1.3  Define  System  Requirements  (Subtask  1.3) 

3.1 .3.1  Establish  GMAP  Requirements 

Identifying  the  data  needs  led  to  the  establishment  of  the  PDD  requirements  of  the  GMAP 
system.  These  requirements  were  synthesized  from  the  results  of  the  needs  analysis  and  are 
presented  in  the  form  of  entities  mapped  to  the  needs  expressed  in  the  NAD  as  well  as  specific 
requirements  to  siipport  RFC  and  IBIS. 

3.1. 3.1.1  PDD  Requirements 

Tables  3-15  through  3-21  below  summarize  the  entities  required  to  be  represented  for  each 
data  class. 
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TABLE  3-16. 

GEOMETRY  DATA  ENTITY  REQUIREMENTS 


Baie  Surface 

2-D  Circlular  Arc 

B-Spline  Surfiue 

2-D  Cloaed  Curve 

Cone 

2-D  Conic  Arc 

Constructive  Surface 

2-D  Coordinate 

CRV  STR2  Profile 

2-D  Curve 

CRV  STR3  Profile 

2-D  Curve  Segment 

Curvc2  Profile 

2-D  Curve  Segment  Curve  String  Element 

Curves  Profile 

2-D  Curve  String 

Cylinder 

2-D  Curve  String  Elenrent 

nef  Coords 

2-D  Ellipse 

Def  Coords 

2-D  Geometric  Element 

TW  Points 

2-D  Line 

Dv  ■  Points 

2-D  Matrix 

DEt  PTS 

2-D  Open  Curve 

DEF 

2-D  Open  Curve  String  Element 

Elztrusion 

2-D  Point 

Geometric  Element 

2-D  Polynomial  Spline 

Irregular  Curve  Segments 

2-D  Quasi  Geometry 

Irregular  Curve  Segments 

2-D  Vector 

Offset  Surface 

3-D  B-Spline 

Plane 

3-D  Circle 

Points  Boundary  Curve 

3-D  Circular  Arc 

Prefile 

3-D  Cloaed  Curve 

Profile  2-D 

3-D  Conic  Arc 

Profile  S-D 

3-D  Coordinate 

RB  Control  COORDS 

3-D  Curve 

RB  Control  COORDS 

3-D  Curve  Segment 

RB  Control  Points 

3-D  Curve  Segment  Curve  String  Element 

RB  Control  Points 

3-D  Curve  String 

RB-SplineS  Control  Point 

3-D  Curve  String  Element 

RB-SpUneS  Control  Point 

3-D  Ellipse 

Regular  Curve  Segments 

3-D  Geometric  ESement 

Regular  Curve  Segments 

3-D  Line 

Ruled  Surface 

3-D  Matrix 

Sphere 

3-D  Open  Curve 

Surface 

3-D  Open  Curve  String  Element 

Surface  of  Revolution 

3-D  Point 

Trimmed  Surface 

3-D  Polytromial  Spline 

S'D  B -Spline 

3-D  Quasi  Geometry 

S-D  Circle 

3-D  Vector 

nona/u 


3-67 


naam/i 


Cl  FTR560240001U 
September  1989 


TABLE  3-16. 

SHAPE  ELEMENT  DATA  ENTITY  REQUIREMENTS 


Shape  Elemeni 

Vertex 

Edge 

Surface  Area 
Form  Feature 
Feature  Rep. 

Explicit  Feature  Rep. 

Constructive  Feature  Rep. 

Primitive 
Driven  Feature 
Rotational  Feature 
Section  Defined  Feature 
Edge  Modifier 
Chamfer 
Edge  Round 
Relief 
Scallop 

Rectangular  Thru  Slot 
Edge  Round 

Primitive  Feature  Bound 
Implicit  Modifier  Edge 
Thread 

Replicate  Feature 
Replicate  Feature  Omission 
Compound  Constructive  Feature 
Circular  Feature  Pattern 
Circular  Feature  Omission 
Rectangular  Feature  Pattern 
Rectangular  Feature  Omission 
Primitive  Constructive  Feature 
BOR  Groove 
3-D  Rotational  Groove 
3  D  Blind  Hole 
BOR  Blind  Hole 
BOR  Thru  Hole 
Flat  Pattern  Hole 
BREP  Crimp 
BREP  Cutout  Flange 
3-D  Bend 

3-D  Rectangular  Pocket 
Flat  Pattern  Rectangular  Cutout 

2- D  Phantom  Edge 

3- D  Phantom  Edge 
Flat  Pattern  Bend 

Flat  Pattern  Bend  Point 
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TABLE  3-16. 
(CONTINUED) 


Face 

Subf^e 

Zone 

Object 

Simple  Object 
Compound  Object 
FeatuK  of  Size 
Constructed  Geometry 
Geometric  Relation 
Zone  Component 

B2oaa/u 


TABLE  3-17. 

GEOMETRIC  CONSTRUCTION  DATA  ENTITY  REQUIREMENTS 


Construction  Geometry 
Geometric  Relation 
Geometric  Relation  Reference 
saaia/u 
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TABLE  3-18. 

SHAPE  REPRESENTATION  DATA  ENTITY  REQUIREMENTS 


BOR  Edge 
BOR  Face 
BOR  Object 
BOR  Rep  E^ment 
BOR  Shell 
BOR  Sublace 
BREP  Edge 
BREP  Element 
BREP  Face 
BREP  Loop 
BREP  Object 
BREP  Shell 
BREP  Subface 
BREP  Vertex 
Flat  Pattern 

Flat  Pattern  Extruded  Edge 

Flat  Pattern  Extruded  Face 

Flat  Pattern  Extruded  Subface 

Flat  Pattern  Front/Back  Face 

Flat  Pattern  Front/Back  Subface 

Flat  Pattern  Loop 

Flat  Pattern  Object 

Flat  Pattern  Rep  Element 

Flat  Pattern  Segment 

Flat  Pattern  Segment  Intersection 

Flat  Pattern  Vertex 

Laminate  Object 

Laminate  Rep  Element 

Located  Ply  Detail 

Ply 

Ply  Detail 

Ply  Stack _ 

Kxe02/Li 
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TABLE  3-19. 

TOLERANCE  DATA  ENTITY  REQUIREMENTS 


Angulai  Location 
Angular  Siza 
Angularity 
Circtilar  Runout 
Compound  Datum 
Concentricity 
Coordinate  Tolerance 
Curve  Length 
Cylindricity 
Datum 

Datum  Material  Condition 
Datum  Refennce 
Datum  Reference  Frame 
Datum  Target 
Diq>osed  Coordinate 
Flatness 

Geometric  Tolerance 
Individual  Coordinate 
Individual  Geometric 
Individual  Line  Profile 
Individual  Mismatch 
Individual  Surface  Profile 
Material  Condition 
Mismatch 

One  Datum  Reference  Frame 
Parallelism 
Perpendicularity 
Primary  Datum  Reference 
Profile  of  a  Line  _ 


Profile  of  a  SurCua 
Profile  Toieranca 
Projacted  Toieranca  Zone 
Rectilinear  Location 
Rectilinear  Siza 
Related  Coordinate 
Related  Geometric 
Related  Line  Profile 
Related  Miamatch 
Related  Surface  Profile 
Roundness 

Secondary  Datum  Reference 
Simple  Datum 
Single-Sided  Coordinate 
Size  Tolerance  Qualifier 
Straightness 

Tertiary  Datum  Reference 
Three  Datum  Reference 
Frame 
Tolerance 

Tolerance  Material  Condition 
Tolerance  Property 
Tolerance  QuaJifier 
Tolerance  Zone  Indicator 
Toleranced  Shane 
Total  Runout 
True  Position 
Two  Datum  Reference 

Frame _ 

uows/ii 
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INTERNAL  FLAW  CRITERIA 
SURFACE  FLAW  PROXIMITY 
SURFACE  FLAW  LIMIT 
SURFACE  REPAIRABLE  FLAW  LIMIT 
SURFACE  SERVICEABLE  FLAW  LIMIT 
SURFACE  FLAW  DATA 
SURFACE  FLAW  WIDTH 
SURFACE  FLAW  DEPTH 
SURFACE  FLAW  PROXIMITY. 


3.1.3.1.2.2  RFC 


Specific  requirements  identified  to  support  the  RFC  system  are  summarized  below. 

•  Procedures  and  pro^ams  were  required  to  access,  and  sb'^w  "^ue?  of  en^’ities 
needed  in  the  RFC  interface. 


•  The  following  entities  were  required  to  convey  the  3-D  geometry  and  topology 
of  areas  on  the  part  targeted  for  inspection; 

3-D  GEOMETRIC  ELEMENT 

ZONE  COMPONENT 

SURFACE  AREA 
FACE 
SUBFACE 
ZONE 

FORM  FEATURE 

•  The  following  entities  were  required  to  define  a  specific  period  in  the  life  cycle 
of  a  part  to  establish  which  inspection  limits  apply; 

CYCLE 

CYCLE-ZONE  FLAW  CRITERIA. 

•  The  following  entities  were  required  to  indicate  maximum  serviceable  and 
repairable  limits  for  various  flaw  configurations; 


FLAW  CRITERIA 
SURFACE  FLAW  CRITERIA 
INTERNAL  FLAW  CRITERIA 
FLAW  ORIENTATION 
FLAW  CRITERIA  ZONE 
ZONE  FLAW  CRITERIA 
CYCLE  ZONE  FLAW  CRITERIA 
SURFACE  FLAW  DATA 
SURFACE  WIDTH 
SURFACE  DEPTH 
SURFACE  FLAW  PROXIMITY 
FLAW  LIMIT 
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INTERNAL  FLAW  LIMIT 
INTERNAL  REPAIRABLE  FLAW  LIMIT 
INTERNAL  SERVICEABLE  FLAW  LIMIT 
SURFACE  FLAW  UMIT 
SURFACE  REPAIRABLE  FLAW  LIMIT 
SURFACE  SERVICEABLE  FLAW  UMIT. 

•  The  following  entities  were  required  to  convey  revision  information,  part 
identification,  and  material  type: 

PRODUCT 

VERSION 

REVISION 

SPECIFICATION 

MATERIAL 

NONSHAPE  REFERENCE 
MATERIAL  SPECIFICATION  REFERENCE 
MATERIAL  NONSHAPE  ELEMENT  REFERENCE 
NONSHAPE  ELEMENT  PROPERTY  REFERENCE 
NONSHAPE  ELEMENT 
TREATMENT 
HEAT  TREAT 
MISCELLANEOUS 
TENSILE  REQUIREMENTS 

3.1. 3.2  Establish  Minimum  Requirements  of  a  Geometric  Modeling  System 

A  significant  portion  of  the  requirements  definition  included  establishing  the  minimum 
requirements  of  a  product  modeler.  Such  a  modeler  was  required  to  take  advantage  of  the 
complete  PDD  capabilities  provided  by  GMAP.  This  modeler  would  pro'idc  the  capability  to 
create,  manipulate,  and  manage  the  full  spectrum  of  such  data  —  a  capability  not  found  in  any 
existing  system. 

The  results  of  this  product  modeler  work  were  reported  in  Appendix  D  of  the  System 
Requirements  Document  (Cl  SRD560240(X)1U).  Discussions  at  the  fourth  IRB  meeting  indicated 
that  their  were  five  opportunities  to  enhance  this  report: 

•  The  scope  of  stored  PDD  should  be  discussed. 

•  The  management  of  PDD,  as  well  as  the  administrative  data,  needs  to  be 
explored  and  proposed  in  the  document. 

•  Requirements  for  interfaces  to  such  things  as  applications,  databases,  and 
other  systems  should  be  discussed. 

•  The  architecture  of  the  data  generation  modules  should  be  laid  out  for  the 
reader  to  better  understand  what  is  being  explained  in  the  document. 

•  A  number  of  additional  areas  should  have  been  conndered  for  discussion,  and 
others  more  fully  discussed. 
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As  a  result,  Pratt  &  Whitney  contracted  D.  Appleton  Company  (DACOM)  to  produce  a 
follow-on  document  entitled  ‘Tunctional  Requirements  of  a  Product  Modeler”  that  addressed 
these  issues.  That  document  will  be  published  as  Cl  TTD560240003U. 

3.1.3.3  Perform  State-of-the-Art  Survey 

A  survey  was  conducted  to  identify  current  and  emerging  technologies  that  impact  the 
content,  usage,  exchange,  and  management  of  PDO  models.  This  survey  also  identified 
technology  voids  by  correlating  the  prioritized  needs  from  the  GMAP  Needs  Analysis  Document 
with  the  survey  fmdings. 

The  survey  was  conducted  through  the  combined  use  of  questionnaires  and  on-site 
interviews  with  both  users  and  developers  of  CAE/CAD/CAM  systems.  Initially,  questionnaires 
were  mailed  to  the  siuvey  candidates  and  the  responses  were  evaluated  and  documented.  The 
next  step  vas  to  use  on-site  and  telephone  interviews  to  gain  a  more  specific  understanding  of 
key  issues  and  to  help  correlate  the  survey  findings  with  the  data  class  needs. 

The  sur .  'y  explored  a  variety  of  CAE/CAD/CAM  modeling  systems  and  applications  of 
those  systems.  \'Se  survey  investigated  the  types  of  data  exchanged  between  product  modeling 
systems  today,  as  v.  ell  as  the  data  and  information  desired,  but  not  currently  being  exchanged. 

Both  existing  end  emerging  technological  cspabilities  were  surveyed  to  forecast  new 
developments  which  may  contribute  to  the  GMAP  project.  Technology  trends  that  potentially 
impact  the  manner  in  which  data  are  created,  stored,  controlled,  managed,  and  communicated 
were  stressed. 

Two  different  questionnaires  were  developed  for  the  survey.  The  first  was  intended  for 
developers  of  technology  pursuant  to  GMAP  needs.  The  second  was  for  users  of  modeling 
software  and  applications  impacted  by  GMAP.  Questionnaires  were  mailed  to  approximately  100 
survey  candidates.  Telephone  follow-up  was  made  with  the  individuals  being  surveyed  to 
maximize  the  level  of  participation.  The  survey  responses  were  evaluated  to  refine  the  on-site 
interview  questions  and  candidate  lists,  and  the  results  were  documented. 

Survey  candidates  were  selected  that  best  met  the  objectives  of  the  survey,  including: 

•  GMAP  team  members 

•  Turbine  blade  and  disk  siq>pliers 

•  CAE/CAD/CAM  system  vendors 

•  Major  users  of  CAE/CAD/CAM  systems. 

The  results  of  the  survey  were  presented  in  the  State-of-the-Art  Document  (Cl 
SAD5602240001U).  dated  27  March  1987,  in  four  categories: 

•  Available  Technologies  —  Examined  user  needs  and  curit.nt  technology  for 
relevant  technologies 


•  Needed  Tc'ihnninnies  —  *'b"t  ve  needed  to  advance 

the  state  of  the  art 
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•  Technology  Trends  —  Described  technology  trends  that  several  manufactur¬ 
ers  and  software  developers  are  following 

•  Correlation  With  Needs  Analysis  —  Poetised  on  the  availability  of  modeling 
and  explication  software  systems  for  creating  and  using  each  of  the  data 
classes  identified  in  the  needs  analysis. 

In  summary,  it  was  found  that  completely  integrated  product  modelers  are  not  yet  available. 
Most  of  the  modeling  being  done  by  system  users  was  done  to  satisfy  a  particular  explication.  For 
instance,  two-dimensional  views  of  an  object  were  modeled  for  use  in  dra^ng.  Three- 
dimensional  wireframes  and  surfaces  were  created  to  represent  a  particular  area  on  a  part  to  be 
used  for  developing  an  N/C  tool  path  definition.  A  rough  (nondetailed)  solid  representation  of 
the  part  was  modeled  for  calculation  of  volume  or  moment  of  inertia.  Manufacturing  features 
were  identified  and  stored  for  group  technology  or  process  planning. 

The  variety  of  computer  applications  was  increasing  throughout  manufacturing  enterprises. 
Software  systems  to  support  design  and  analysis,  manufacturing,  quality,  product  support,  and 
logistics  support  functions  have  been  implemented  by  SOA  survey  participants.  The  proliferation 
of  applications  in  such  diverse  areas  was  placing  great  demands  on  both  the  quality  and  quantity 
of  available  PDD. 

Most  of  the  users  surveyed  were  in  the  process  of  linking  together  their  “islands  of 
automation”  with  some  type  of  application  interface  software.  One  portion  of  this  linking  process 
dealt  with  applications  that  require  PDD  in  some  format.  Many  different  ways  were  being  used 
to  accomplish  this,  ranging  from  direct  translators  to  system-wide  common  neutral  files. 

Management  of  digital  drawings  was  based  on  native  system  file  management  capabilities 
and  existing  procedures  for  release  and  control  of  paper  drawings.  However,  several  system 
developers  had  announced  software  products  developed  specifically  for  management  of  comput¬ 
erized  product  data. 

3. 1.3.4  Review  Requirements  Definition 

A  thorough  discussion  of  the  efforts  described  above  in  Section  3.1.3  were  documented  in 
the  System  Requirements  Document  (SRD560240001U). 

The  main  body  of  the  System  Requirements  Document  was  separated  into  three  major 
sections.  The  first  section  identified  PDD  requirements  mapped  to  the  data  needs  identified  in 
Section  3.5  of  the  Needs  Analysis  Document.  These  requirements  are  stated  in  the  form  of 
bulleted  lists,  along  with  supporting  rationale,  to  provide  an  understanding  of  the  requirements, 
and  to  indicate  how  they  were  derived  from  the  needs. 

The  second  section  of  the  System  Requirements  Document  identifies  enhancements  to  the 
PDOI  software  required  to  support  exchange  system  needs  identified  during  both  the  PDDI  and 
th.’  GMAP  walkthroughs.  Recommendations  were  included  where  requirements  would  be 
important  for  tuture  consideration  but  fall  beyond  the  scope  of  GMAP.  Schema  manager,  access 
software,  and  trsr.slaiur  requirements  are  identirtecL  Needs  were  denved  from  both  the  GMAP 
Needs  Analysis  Document  and  the  PDDI  System  Requirements  Document  (SRD560130000). 
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The  last  section  of  the  System  Requirements  Document  defines  application  requirements 
from  a  generic  viewpoint  and  from  the  viewpoints  of  the  IBIS  and  RFC  systems.  An  important 
objective  of  GMAP  was  to  demonstrate  the  use  of  FDD  by  commu^iicating  and  manipulating 
FDD  to  support  applications  throughout  the  life  cycle  of  turbine  blades  and  disks.  During  the 
investigation  of  the  GMAF  needs,  the  existing  flow  of  product  information  was  examined  and 
arefiS  that  would  benefit  &om  improved  data  flow  and  exchange  were  identified.  The  applications 
stvidied  spanned  the  entire  life  cycle  from  conceptual  design  through  logistics  siq>port. 

'i.2  Task  2  —  Establish  Preliminary  and  Detailed  Design 

Task  2  consisted  of  four  subtasks; 

2.1  Establish  Freliminaiy  Design 

2.2  Review  Freliminaiy  Design 

2.3  Establish  Detail  Design 

2.4  Perform  Critical  Design  Review. 

In  Subtask  2.1,  a  preliminary,  or  conceptual,  design  for  GMAP  was  developed,  including 
identification  of  required  enhancements  to  PDDI  technology  and  a  plan  for  testing  the  GMAP 
s)  stem  software.  In  subtask  2.2,  this  work  was  reviewed  to  ensure  that  the  design  met  all  of  the 
system  requirements  established  in  Task  1.  Subtask  2.3  detailed  the  design,  and  established  plans 
for  testing  logistic  application  interfaces.  Subtask  2.4  ensured  review  of  the  detail  design. 

3.2.1  Establish  Preliminary  Design  (Subtask  2.1) 

To  establish  a  preliminary  design,  IDEFlX  information  modeling  was  performed  for  each 
data  class.  Overview  diagrams  of  the  information  models  were  produced  for  communication  and 
review.  The  content  and  capability  of  each  data  class  were  presented  to  an  open  audience  of 
knowledgeable  reviewers  for  comment. 

The  IDEFlX  information  model  was  verified  and  refined  using  a  commercial  computer 
software  product.  After  verification  of  the  IDEFlX  information  model,  the  lexical  form  of  the 
conceptual  schema  in  the  EXPRESS  language  was  produced.  The  lexical  schema  specification 
accompanied  the  graphic  schema  specification  that  was  documented  in  the  GMAP  System 
Specification  and  related  documents.  Those  documents  are  summarized  below.  Their  relation¬ 
ship  is  depicted  in  Figure  3-21. 

Volume  II  described  the  exchange  file  format,  which  is  the  PDES  file  format.  Volume  III 
provided  an  IDEFlX  Readers  Guide  and  the  GMAP  IDEFlX  Information  Model.  The 
information  model  was  presented  in  page-pair  format  with  a  subject  entity  diagram  and  an 
accompanying  entity  definition  page.  Volume  IV  consisted  of  an  EXPRESS  language  specifica¬ 
tion  and  the  GMAP  EXPRESS  Abstract  Schema  specification  with  illustrations  and  definitions. 
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Figure  3-21.  Interrelationship  of  GMAP  Documents 

The  majority  of  the  System  Specification  documented  the  GMAP  schema.  The  schema  was 
developed  over  a  period  of  time  during  the  walkthrough  of  the  turbine  blades  and  disks  life  cycle. 

3.2.1.1  Produce  System  Specification 

The  GMAP  System  Specification  (SS)  (Cl  SS56024(X)01U)  consisted  of  four  volumes. 
Volume  I  described  four  major  components  of  the  GMAP  system: 

•  Conceptual  Schema 

•  Schema  Manager 

•  Model  Access  Software  with  N/VI 

•  System  Translator. 

As  described  under  Task  1,  investigations  and  interviews  were  conducted  throughout  the 
disciplines  involved  in  the  life  cycle  of  these  products.  An  IDEFO  function  model  was  created 
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from  the  information  gathered  The  objective  of  the  IDEFO  function  model  was  to  identify  the 
functional  implications  involved  in  the  blade  and  disk  life-cycle.  The  functional  ^>plications 
identified  were  subjected  to  further  scoping  and  a  final  set  of  fiinctional  applications  was  chosen. 

The  selected  functional  implications  were  then  used  as  targets  in  the  IDEIFIX  Information 
Modeling  Methodology.  This  methodology  was  ^>plied  to  the  applications,  and  the  data  captured 
included  the  entities,  attributes,  and  relationships  involved  The  EDEFIX  diagrams  were 
manually  prepared  and  then  verified  for  accuracy  by  using  the  JANUS  software  product 
marketed  by  DACOM.  The  validated  corrected  model  was  then  documented  in  Volume  III  of  the 
GMAP  System  Specification.  The  diagrams  were  produced  by  an  IDEFlX  diagramming  program 
prepared  by  UTRC.  The  validated  entity  and  attribute  names,  and  the  relationship  tert  were 
transferred  from  the  JANUS  work. 

The  JANUS  work  also  created  a  structured  modeling  language  ou^ut  This  lexical  form  of 
the  information  model  was  used  as  input  to  a  prototype  translator  to  create  an  initial  EXPRESS 
language  version.  That  EXPRESS  translation  was  manually  conditioned  into  an  appropriate 
GMAP  Abstract  Schema  and  published  in  Volume  IV  of  the  GMAP  System  Specification. 

3.2.1.2  Produce  System  Design  Specification 

The  System  Design  Specification  (Cl  SDS560240()01U)  transformed  the  requirements 
stated  in  the  GMAP  System  Specification  into  a  conceptual  design  to  build  the  system. 
Primarily,  the  System  Design  Specification  consisted  of  information  on:  the  Schema  Manager, 
the  MAS  with  N/VI,  and  the  System  Translator;  the  GMAP-to-IBIS  Interface;  and  the  GMAP- 
to-RFC  Interface. 

The  main  body  of  the  System  Design  Specification  discussed  ten  major  areas  of  interest  on 
these  configuration  items.  These  included: 

•  System  definitions 

•  System  characteristics 

•  Data  characteristics 

•  Application  interfaces 

•  Design  and  construction  standards 

•  Information  regarding  GMAP  system  documentation 

•  Facilities  and  equipment 

•  Training  and  system  installation. 

The  System  Design  Specification  contained  a  detailed  definition  of  the  GMAP  system 
components  and  the  application  interfaces  developed  at  Pratt  &  Whitney.  The  RFC  and  IBIS 
application  interfaces  were  documented  in  the  two  Development  Specifications,  Cl 
DS560240011U  and  Cl  DS560240021U,  respectively. 

3.2.1. 3  Produce  System  Test  Plan 

The  System  Test  Plan  (Cl  STP560240()01U)  provided  a  strategy  for  testing  and  validating 
the  elements  and  functionality  of  GMAP.  The  elements  of  GMAP  were  the  system  components 
as  defined  in  the  System  Design  Specification.  Plans  called  for  the  functionality  of  the  system 
components  to  be  validated  through  application  demonstrations.  The  paragraphs  below  describe 
these  plans  in  more  detail. 
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The  GMAP  software  components  were  to  be  tested  in  several  phases.  The  first  phase  yfcs 
individual  Component  Development  Testing  performed  as  the  component  pn^rams  were 
developed  and  enhanced.  The  second  phase  was  Software  Progtom  Testing.  Acceptance  testing 
was  the  third  phase.  The  fourth  phase  was  System  Integration  Testing/Demonstrations  in  which 
the  GMAP  software  was  used  in  various  CAD/CAM/CAE  ai^Iication  demonstrations.  These 
phases  are  described  below.  All  development  and  testing  was  to  be  done  in  accordance  with  Pratt 
&  Whitney’s  GMAP  Software  Quality  Assurance  plan  (FR  19199-5)  and  MCAIR’s  GMAP 
Software  Quality  Assurance  plan. 

Phase  1  —  Component  Development  Testing.  Individual  component  test  plans  were 
developed  in  accordance  with  Institute  of  Electrical  and  Electronic  Engineers  (IEEE)  software 
test  documentation  standards  and  are  presented  in  the  appendices  of  the  System  Test  Plan. 

Phase  2  —  Software  Program  Testing  was  planned  for  two  basic  versions:  a  “Prototype” 
version  and  a  “Test”  version. 

The  “Prototype”  version  was  pseudo-stable  software  developed  for  testing,  training,  and 
familiarization  purposes.  This  software  used  data  and  models  derived  from  the  GMAP 
Conceptual  Schema.  This  prototype  version  consisted  of  the  MAS  with  the  N/VI,  and  the 
System  Translator  incorporating  the  PDES  file  structure  and  the  data  dictionary. 

The  “Test”  version  was  developed  for  general  testing  of  the  GMAP  enhanced  PDDI 
software  and  for  building  interfaces  to  demonstration  applications.  This  test  version  consisted  of 
the  MAS  from  the  prototype  version,  an  enhanced  System  Translator,  the  N/VI,  and  the  Schema 
Manager. 

Phase  3  —  Acceptance  Testing  for  the  test  version  included  plans  for  using  a  sample  model 
developed  from  the  GMAP  schema  using  the  following  concepts.  'The  sample  model  contained 
entities  made  up  of  all  possible  combinations  of  primitives.  These  primitives  were:  integers  and 
real  numbers,  characters,  logicals,  scalars,  pointers,  and  arrays.  The  use  of  existing  entity  types 
in  the  testing  ensured  that  any  entity  created  would  translate  correctly.  All  software  was  tested 
using  this  acceptance  model. 

The  Acceptance  Test  scenario  is  shown  in  Figure  3-22.  This  Acceptance  Test  simulated  the 
processing  of  data  through  the  GMAP  system.  The  Schema  Manager  was  used  to  convert  the 
(Conceptual  Schema  to  physical  schema  (PASCAL  include  files  or  data  dictionary  files).  These 
physical  schema  files  were  used  to  create  part  models  which  were  translated  to  and  from 
exchange  format  files. 


Phase  4  —  System  Integration  Testing/Demonstrations.  A  basic  strategy  for  testing  the 
GMAP  components  was  to  demonstrate  the  functionality  of  the  GMAP  system.  In  this  phase, 
complete  PDD  would  be  defined  and  transferred  to  show  the  transportability  of  the  software  and 
the  PDD.  Several  demonstrations,  summarized  below,  were  planned  to  ahow  the  integration  of 
the  GMAP  software  with  various  application  software. 
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FOA  344799 


Figure  3-22.  Acceptance  Test  Scenario  and  Criteria 


Candidate  applications  were  identified  during  the  IDEFO  functional  walkthroughs  and 
revisited  during  test  planning.  Figure  3-23  contains  a  matrix  of  the  final  applications,  indicating 
life-cycle  area  and  part  class.  A  high  level  breakdown  of  the  GMAP  PDD  usage  for  each  of  these 
test  applications  by  data  class  is  presented  in  Table  3-22. 
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Figure  3-23.  Matrix  of  GMAP  Demonstrations 

3.2.1. 3.1  Parametric  Cooled  Turtrfne  Blade  Design 

This  application  would  demonstrate  how  the  elements  o'  the  solid  part  are  integrated  in  a 
complete  model  and  show  that  rapid  changes  are  possible  with  minimum  rework.  The  model 
created  in  this  application  was  represented  in  GMAP  PDD  form  and  supported  downstream 
demonstration  applications. 

3.2. 1.3.2  Casting  Tooling  Applications 

The  casting  tooling  application  would  be  a  comprehensive  demonstration  of  the  use  of 
GMAP  in  supporting  the  manufacture  and  inspection  of  turbine  blades.  There  were  four  major 
elements  of  this  demonstration  planned: 

•  Pratt  &  Whitney  Internal  Numerical  Control  (N/C)  Electrode  Machining 

•  Supplier  N/C  Electrode  Machining 

•  Coordinate  Measuring  Machine  (CMM)  Inspection 

•  Automated  Optical  Inspection. 

3.2. 1.3.3  Integrated  Blade  Inspection  System  (IBIS) 

IBIS  is  the  automated  blade  inspection  system  for  the  San  Antonio-Air  Logistics  Center 
(SA-ALC)  logistics  support  facility.  More  information  on  this  application  can  be  found  in  Task  3, 
Integrate  Existing  Functional  Applications. 
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TABLE  3-22. 
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3.2.1.3.4  Disk  Design 

The  disk  design  applic8*ion  would  demonstrate  how  design/drafting  data  moved  from 
initial  design  c.ncept  to  tind  detail  design.  This  application  would  also  show  how  this  data  was 
intelligently  interpreted  and  converted  to  GMAP  format  for  exchange  to  demonstration 
applications  downstream  in  the  manufacturing  proces.s. 

3.2.1. 3.5  PROcess  CAPability  (PROCAP) 

The  PROCAP  application  would  provide  feedback  to  the  engineering  and  process  plannirg 
functions.  The  demonstration  would  show  the  use  of  unconventional  PDD,  such  as  features  and 
tolerances,  within  the  PDD  Editor  to  retrieve  the  process  capabilities  of  manufacturing 
operations  that  create  similar  features. 

3.2. 1.3.6  Feature-Based  N/C  Machining  and  CMM  Inspection  of  Disk  Features 


The  Feature-based  N/C  and  CMM  Programming  application  planned  to  use  form  feature 
entities,  attributes  and  relationships  in  a  GMAP  model  to  produce  source  code  programs  for 
machining  and  inspecting  disk  features.  This  demonstration  showed  how  GMAP  PDD  could 
enable  more  intelligent  applications  to  be  added  to  the  life  cycle. 
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3.2.1.3.7  Disk  Forging 

The  disk  forging  application  would  demonstrate  the  electronic  transmittal  of  a  Supplier 
Report  of  Nonconformance  (SRON)  from  a  disk  forging  supplier  to  Pratt  &  Whitney,  using 
GMAP.  The  electronic  SRON  would  include  a  finished  disk  profile  sxQ)erimposed  on  the  forging 
shape,  and  dimensions  and  tolerances  afiected  by  the  nonconformance. 

3.2.1.3.8  Retirement  for  Cause  (RFC) 

The  RFC  system  is  an  automated,  robotics-based  inspection  system  developed  by  Systems 
Research  Laboratories  (SRL)  in  Dayton,  Ohio,  for  the  SA-ALC.  More  information  on  this 
application  can  be  found  in  Task  3,  Integrate  Existing  Functional  Applications. 

3.2. 1.3.9  Boss  Inspection  Using  Dimensional  Measuring  Interface  Specification 

Plans  for  the  Engine  Case  Boas  inspection  demonstration  involved  the  use  of  a  CAD  based 
geometric  modeling  environment,  a  case  plumbing  attachment  boss  FDD  model,  a  neutral 
exchange  system  to  communicate  the  product  models,  computer  controlled  dimensional 
inspection  equipment,  and  a  neutral  interface  to  communicate  inspection  programs  and  data. 

The  primary  objective  of  this  demonstration  was  to  show  how  a  GMAP  PDD  model  of  an 
engine  case  boss  can  enable  the  automation  of  the  ins]>ection  planning  function.  A  secondary 
objective  was  to  demonstrate  the  use  of  the  Dimensional  Measuring  Interface  Specification 
(DMIS)  neutral  format  for  communiratia^  inspection  programs  from  a  CAD  assisted  in^>ection 
plan  generation  system  to  a  computer  controlled  coordinate  measuring  machine.  This  demon¬ 
stration  was  planned  as  a  joint  effort  between  Pratt  &  Whitney  and  Rensselaer  Polytechnic 
Institute. 


3.2.1.3.10  Case  Boss  N/C  Programming 

Plans  also  called  for  an  engine  case  plumbing  attachment  boss  to  be  built,  transferred  and 
used  to  generate  and  verify  N/C  programs  for  machining  the  boss.  The  primary  objective  of  this 
demonstration  would  be  to  show  that  GMAP  could  support  simpler,  more  typical  parts  than 
turbine  blades  and  disks.  Another  goal  would  be  to  show  that  GMAP  components  could  provide 
the  PDD  required  by  form  feature-based  applications. 

3.2. 1.4  Enhancements  to  PDDI  Software 

GMAP  software  was  based  on  software  developed  for  the  PDDI  project.  Thus,  enhance¬ 
ments  to  the  PDDI  software  were  required  to  support  exchange  system  needs  identified  during 
the  GMAP  walkthroughs. 

Enhancements  or  additions  were  identified  is  four  areas: 

•  PDD  model  access 

•  Schema  Manager 

•  PDD  Editor 

•  System  Translator  performance  improvements. 
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3.2. 1.4.1  POD  Model  Access 

An  enhancement  to  the  PDDI  MAS  called  the  “Name/Value  Interface”  (N/VI)  was 
designed  to  permit  greater  data  independence  in  the  software.  This  enhancement  would  enable 
more  sophisticated  applications  to  readily  take  advantage  of  the  data  richness  in  a  PDD  model  by 
using  an  established,  and  maintained,  set  of  access  utilities. 

The  MAS  supported  access  at  the  entity  level.  Applications  desiring  access  to  any  part  of 
the  entity’s  attributes  required  the  application  to  retrieve  and  return  the  entire  attribute  data 
block.  Attributes  were  accessed  by  including  the  attribute’s  physical  locations  in  the  data  block 
into  the  source  code  at  compile  time.  The  N/VI  would  require  only  the  name  and  type  of  the 
attribute  to  be  declared  internally  to  the  application.  A  call  to  the  N/VI  with  the  desired  entity 
key  would  perform  the  physical  mappings  and  accesses,  and  then  return  the  attribute  value  only 
for  that  given  attribute  name. 

Thus,  the  N/VI  would  free  application  programs  from  the  need  to  be  concerned  with  the 
physical  location  of  attribute  values  within  an  entity  in  the  working  form  of  the  product  model. 
Using  the  N/VI,  the  only  knowledge  an  application  would  require  is  the  schema  definition,  the 
desired  entity  key,  and  the  desired  attribute’s  name  and  type.  'This  would  permit  physical 
restructuring  of  the  attribute  data  'clock  to  improve  performance  and  storage  costs  without 
requiring  any  modification  to  application  software. 

The  N/VI  design  consisted  of  three  parts: 

•  Attribute  data  structures 

•  Direct  query/store  subprograms 

•  Procedural  query  subprograms. 

The  attribute  data  structures  would  be  compiled  into  application  programs,  providing  the 
definition  of  the  N/VI  data  transfer  block. 

The  direct  query/store  subprograms  would  be  provided  for  applications  that  had  high  access 
and  retrieval  rates  for  only  a  few  entities,  and  only  specific  attributes  that  they  possess.  The 
added  overhead  of  mapping  and  small  block  size  transfers  would  be  balanced  off  against  the 
newly  gained  application  data  independence.  Binding  to  the  schema  would  occur  at  nm  time  by 
accessing  the  data  dictionary. 

Procedural  query  subprograms  would  be  an  access  ability  that  applications  could  use  to 
produce  lists  of  entities  that  may  have  similar  attribute  values,  such  as  a  list  of  all  0.250' 
diameter  holes.  This  would  eliminate  a  great  deal  of  the  MAS  chores  and  comparison  strategy 
from  the  application  and  put  them  into  the  MAS.  In  this  case,  schema  binding  would  occur  at  run 
time  by  accessing  the  data  dictionary. 

The  MAS  with  N/VI  is  described  in  more  detail  in  the  GMAP  System  Specification 
(Cl  SS560240001U),  System  Design  Specification  (Cl  SDS560240001U),  System  Component 
As-built  Product  Specification  Product  Specification  (Cl  PS560240032U),  Model  Access 
Software  User’s  Manual  (Cl  UM560240031U),  and  the  System  Components  Oi^rator’s  Manual 
(Cl  OM560240001U). 
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3.2. 1.4.2  Schema  Manager 

Another  enhancement  to  the  PDDI  aoftware  was  the  added  capability  to  automatically 
create  and  maintain  the  conceptual  schema  and  its  implementations  throughout  the  software 
modules.  This  capability  was  called  the  “Schema  Manager”.  The  existence  of  the  Schema 
Manager  would  improve  the  flexibility  of  the  software  for  both  growth  and  development. 

The  Schema  Manager  was  necessary  to  create  entity  definitrona.  The  capability  tc  query, 
modify,  or  delete  these  definitions  and  the  ability  to  generate  the  physical  schema  (application 
view)  from  the  conceptual  schema  were  also  required.  The  Schema  Manager  design  iiKluded 
mechanisms  to: 

1.  Isolate  the  interactivB  user  interface  from  tiie  mainline  programs,  minimiz¬ 
ing  the  effort  of  implementing  the  Schema  Manager  on  different  terminals 
and  enabling  batch  input 

2.  Modify  the  content  of  the  metamodel  elements,  based  on  the  experience 
gained  from  the  original  PDDI  effort 

3.  Improve  integrity  and  normalization  by  assuring  uniqueness  of  names  in  the 
appropriate  scope 

4.  Produce  a  run-time  subschema  for  use  by  the  N/VI  to  map  a  data  request 
from  application  programs  to  the  physical  structure  of  an  entity  in  the 
working  form,  and  for  run-time  binding  of  the  schema  to  the  application 

5.  Produce  Pascal  Include  Files  to  define  a  physical  subschema  in  a  format  that 
can  be  inserted  into  a  source  program  for  compile  time  binding  of  the  schema 
to  the  application 

6.  Produce  a  formatted  report  of  the  entity  definitions  contained  in  the 
conceptual  schema. 

The  Schema  Manager  is  described  in  more  detail  in  the  GMAP  System  Specification  (Cl 
SS560240001U),  System  Design  Specification  (Cl  SDS56024(X)01U),  System  Component  As- 
built  Product  Specification  Product  Specification  (Cl  PS56024(X)32U),  Schema  Manager  User’s 
Manual  (Cl  UM56024001  lU),  and  the  System  Components  Operator’s  Manual  (Cl 
OM560240001U). 

3.2.1.4.3  POD  Editor 

The  PDD  Editor  was  designed  to  populate  PDD  models  with  entities  as  defined  in  the 
schema.  It  could  also  create,  modify,  delete,  and  view  the  PDD  contained  in  the  working  form 
model  The  PDD  Editor  would  bridge  the  gap  between  existing  modelers  that  create  conventional 
PDD,  or  a  subset  of  the  GMAP  PDD,  and  those  that  are  referied  to  as  “product  modelers,”  that 
support  the  complete  spectrum  of  PDD  as  defined  in  the  GMAP  schema.  This  software  was 
necessary  to  create  the  GMAP  models  for  the  demonstration  aiq)lications,  not  to  test  the  GMAP 
concepts  or  system  components. 
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The  PDD  Editor  was  designed  to  use  the  grs^hics  capabilities  found  in  the  IBM  GraPhigs 
system.  This  graphics  system  provided  complicated  display  functions  and  manipulation  of 
graphical  entities.  The  PDD  Editor  display  capabilities  include  the  display  of  geometric  entities 
and  their  labels.  Additional  commands  provide  for  the  complete  interrogation  of  displayable  and 
nondisplayable  entities  in  the  PDD  model. 

The  PDD  Editor  is  described  in  more  detail  in  the  GMAP  PDD  Editor  User/Operator 
Manual  (Cl  U/OM56024(X)31U),  and  the  System  Components  Curator’s  Manual 
(Cl  OM560240001U/SCN-1). 

3.2.1. 4.4  System  Translator  Performance  Improvements 

The  System  Translator  is  a  software  mechanism  developed  under  PDDI  for  passing  data 
between  dissimilar  systems.  The  translator  had  a  preprocessor  which  translated  the  internal 
working  f  rm  from  the  sending  system  into  an  exchange  format  file,  and  a  postprocessor  which 
translated  the  exchange  format  file  into  the  receiving  system  internal  working  form. 

Enhanc.  ents  would  also  have  to  be  implemented  to  make  the  System  Translator  conform 
to  the  PDES  ex.  .^nge  format.  During  the  program,  several  additional  enhancements  were  made 
that  reduced  the  CPU  time  for  System  Translator  operation. 

The  System  Translator  is  described  in  more  detail  in  the  GMAP  System  Specification 
(Cl  SS560240(X)1U),  System  Design  Specification  (Cl  SDS56024(X)01U),  System  Component 
As-built  Product  Specification  Product  Specification  (Cl  PS560240032U),  System  Translator’s 
User’s  Manual  (Cl  UM56024(X)21U),  and  the  System  Components  Operator’s  Manual 
(Cl  OM560240001U). 

3.2.2  Review  Preliminary  Design  (Subtask  2.2) 

Review  of  the  progress  and  the  technical  adequacy  of  the  GMAP  system  design  was 
conducted  as  part  of  the  the  third  IRB  meeting  during  ^ril  1987.  The  key  information  presented 
at  that  meeting  was  to  explain  the  enhancements  required  to  PDDI  software  that  were  required 
to  support  the  GMAP  interface  architecture:  the  Schema  Manager,  the  Name/Value  Interface, 
the  PDD  Editor,  and  the  System  Translator.  Also  reviewed  were  the  demonstrations  planned  to 
test  the  GMAP  concepts. 

3.2.3  Establish  the  Detail  Design  (Subtask  2.3) 

3.2.3.1  Establish  the  Product  Specifications 

3.2.3.1.1  System  Components 

The  GMAP  System  Component  As-designed  Product  Specification  (Cl  PS560240031U) 
established  the  design  of  the  GMAP  System  Components.  The  document  described  the  structure, 
functions,  language,  database  requirements,  interfaces  and  quality  assurance  provisions  of  the 
system  components:  the  Schema  Manager,  Model  Access  Software  with  Name/Value  Interface, 
and  the  System  Translator. 
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The  System  Component  As-designed  Product  Speciflcation  consisted  of  four  volumes. 
Volume  I  contained: 

•  Section  1  —  An  introduction,  describing  the  function  of  the  primary 
GMAP/PDDI  system  components  at  a  high-level,  and  summarizing  this 
document. 

•  Section  2  —  Reference  documents  and  terms  and  acronyms  used  in  this 
document. 

•  Sections  3  through  3.9  -  A  System  Overview,  IDEFO  Function  models, 
application  interfaces,  program  interrupts  and  other  design  details. 

Volume  n  contained  the  routine  listings  for  the  Schema  Manager.  Volume  III  contained  the 
routine  listings  for  the  MAS  and  N/VI.  Volume  IV  contained  the  routine  listings  for  the  System 
Translator,  and  Quality  Assurance  provisions. 

The  GMAP  System  Component  As-built  Product  Specification  Product  Specification 
(Cl  PS560240032U)  presented  the  design  of  the  GMAP  System  Compotients  after  the  final 
software  was  built,  tested,  and  debugged. 

3.2.3.1.2  Retirement  for  Cause  and  Integrated  Blade  Inspection  System 

The  GMAP-to-RFC  Interface  Product  Specification  (Cl  PS560240011U)  and  the  GMAP- 
to-IBIS  Interface  Product  Specification  (Cl  PS56024(X)21U)  are  discussed  under  Task  3, 
Integrate  Existing  Functional  Applications. 

3.2.3.2  Establish  the  Unit  Test  Plans 

The  GMAP-to-RFC  Unit  Test  Plan  (Cl  UTP56024(X)11U)  and  the  GMAP-to-IBIS 
Interface  Unit  Test  Plan  (Cl  UTP560240021U)  are  discussed  in  Task  3,  Integrate  Existing 
Functional  Applications. 

3.2.4  Perform  Critical  Design  Review 

A  critical  design  review  is  usually  conducted  by  the  Air  Force  to  determine  if  the  detailed 
design  satisfies  ail  the  requirements  established  in  the  System  Design  Specification,  Product 
Specifications  and  other  design  documents.  Because  of  the  close  coordination  with  the  Air 
Force/IRB  in  establishing  the  detail  design,  no  formal  critical  design  review  was  performed  on 
GMAP.  However,  an  informal  critical  design  review  was  conducted  in  January  1988  at  Dayton, 
Ohio  for  the  Air  Force  Project  Manager. 

3.3  Task  3  —  Integrate  Existing  Functional  Applications 

Task  3  consisted  of  efforts  similar  to  Task  2  (L  e..  Preliminary  Design,  Detail  Design) 
except  that,  in  Task  3,  work  focused  on  the  RFC  and  IBIS  Interfaces  rather  than  the  GMAP 
system  software  compcmenta.  The  foundatiofi  for  this  work  was  traceable  back  to  the 
walkthroughs  conducted  in  the  needs  analysis  and  requirements  definition  conducted  in  Task  1. 
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Within  the  Logistic  Support  function,  three  separate  areas  were  investigated.  First,  a 
subteam  was  formed  to  create  a  model  of  the  San  Antonio  Air  Logistics  Center  (SA-ALC).  This 
subtearj  consisted  of  ITI  investigators  who  interviewed  personnel  at  SA*ALC. 

The  second  and  third  subteams  were  formed  to  investigate  two  qiecific  functional 
applications  currently  being  installed  at  SA-ALC.  These  ^plications  are  the  IBIS  and  RFC  disk 
in'ipection  system.  IBIS  and  RFC  were  selected  because  they  afforded  the  ability  to  investigate  a 
process  that  was  being  automated,  yet  still  had  manual  interface.  IBIS  and  RFC  could  benefit 
,Tom  tbe  development  of  a  computer  interface  that  provided  the  necessary  FDD  input. 

The  IBIS  subteam  consisted  of  representatives  from  ITI  who  interviewed  SA-ALC  and 
General  Electric  (Evandale,  Ohio)  personnel  involved  in  the  implementation  and  development  of 
the  IBIS  system.  The  RFC  subteam  consisted  of  representatives  from  MCAIR  who  interviewed 
SA-ALC  and  Systems  Research  Laboratories  personnel  involved  in  the  implementation  and 
development  of  the  RFC  system.  The  findings,  reported  in  the  Needs  Analysis  Document 
(Cl  NAD560240001U)  and  System  Requirements  Document  (Cl  SRD56024(X)01U),  were  used  to 
design  the  GMAP  interfaces  to  RFC  and  IBIS. 

3  3.1  Establish  Interface  to  Disk  Inspection 

The  RFC  Interface  prototype  was  included  in  GMAP  to  demonstrate  that  a  FDD  model 
transported  via  the  GMAF  system  software  can  support  the  needs  of  the  RFC  logistics  system. 
The  RFC  inspection  system  was  developed  by  a  team  of  aerospace  companies  headed  by  Systems 
Research  Laboratories.  The  objective  of  the  system  was  to  provide  the  United  States  Air  Force 
with  a  nondestructive  evaluation  capability  to  conduct  consistently  high  reliability  inspections 
on  critical  turbine  engine  components.  This  high  reliability  was  essential  to  the  “retirement  for 
cause”  philosophy  which  was  to  reuse  expensive  engine  components  until  an  unacceptable  defect 
is  found,  instead  of  retiring  those  components  at  an  analytically  predetermined  point. 

The  major  operations  of  the  RFC  ^tem  were: 

•  generate  a  scan  plan  that  provided  both  the  geometry  of  areas  on  the  disk 
targeted  for  inspection,  and  inspection  paths  on  these  areas  for  specific 
robotic  cell  (ultrasonic/Eddy  current)  inspection 

•  inspect  the  disk  using  ultrasonic/Eddy  current  robotic  cells  to  collect  anomaly 
data  and  potential  flaws 

•  anal}^  the  flaw  data.  Flaws  were  ompared  with  flaw  criteria  to  determine 
the  status  of  the  disk  as  acceptable,  rejectable,  or  as  inspection  incomplete. 
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3.3.1.1  RFC  Interface  Preliminary  Design 

The  RFC  Interface  provided  POO  from  the  GMAP  model  to  the  RFC  dialc  inspection 
system.  The  two  major  functions  of  the  GMAP>to-RFC  Interface  were  to: 

1.  Translate  the  GMAP  disk  model  POO  from  exchange  format  to  working 
form  in  VAX  computer  memory 

2.  Translate  the  model  in  working  form  to  the  Unigraphics  data  base  that  is 
resident  on  the  RFC  system  at  Systems  Research  Laboratories. 

A  schematic  of  the  RFC  Interface  using  a  part  model  transferred  from  Pratt  &  Whitney  is 
illustrated  in  Figure  3-24. 


Part  Model 


System  'A* 
(IBM) 


VAX  System 


Figure  3-24.  RFC  Interface  System 
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The  POO  model  provided  the  following  data  to  support  RFC  scan  plan  generation  and  flaw 
data  analysis: 

•  Complete  3-0  geometric  definition  of  the  disk  model 

•  Surfaced  areas  on  the  part  targeted  for  inspection  (zones) 

•  Inspection  interval  indicator  (cycles) 
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•  Standards  and  parameters  for  evaluation  of  potential  flaw  data  collected 
during  inspection  (flaw  criteria).  (Flaw  criteria  specified  maximum  “accept¬ 
able  for  service’’  limits  on  flaw  size,  number  of  flaws  per  area,  and  flaw 
orientation  for  specific  zones  on  the  part.  Flaw  criteria  were  defined  within 
two  categories,  surface  flaws  and  internal  flaws.) 

The  IDEFO  function  modeling  methodology  used  for  modeling  the  product  life  cycle  was 
also  used  with  RFC.  A  hierarchical  representation  of  the  RFC  Interface  is  shown  in  Figure  3-25 
as  a  high  level  IDEF  model 

•  A-0,  the  RFC  Software,  translates  the  GMAP  disk  model  from  exchange 
format  into  a  Unigraphics  format  model  This  is  a  top  system  view. 
Component  systems  follow. 

•  AO,  the  RFC  Interface,  consists  of  the  PDES  Postprocessor  and  RFC 
Conversion  Routines. 

•  Al,  the  PDES  Postprocessor,  converts  the  model  from  the  exchange  format 
into  a  memory  resident  working  form. 

•  A2,  RFC  Conversion  Routines,  converts  a  working  form  model  into  Unigraph¬ 
ics  format. 

•  A21,  Initialize  the  Unigraphics  model  lop  the  process  into  the  Unigraphics 
File  Manager  and  allows  allocation  of  an  empty  Unipaphics  file  for  the 
Unipaphics  model  that  vrill  be  built  by  the  RFC  Conversion  Routines. 

•  A22,  Convert  Entities,  consists  of  four  working  form  to  Unipaphics 
conversion  modules,  grouped  by  specific  entity  categories  to  custom  fit  the 
propam  algorithm  and  GMAP  schema.  The  calling  order  of  these  routines  is 
important  for  the  separation  of  noncycle  entities  from  cycle  entities  to 
ultimately  produce  cycle-specific  Unipaphics  part  files  from  the  master 
GMAP  working  form  model.  The  remaining  unprocessed  entities  will  be 
converted  to  Unipaphics  groups  with  members  and  attributes  that  corre¬ 
spond  to  the  entity  relationships  in  the  original  working  form  model  using  a 
“generic”  algorithm. 

•  A221,  Convert  Simple  Geometry,  converts  all  simple  curves  in  the  working 
form  model  into  corresponding  curves  in  the  Unigr^hics  model 

•  A223,  Convert  Cycle  Related  Entities,  deals  with  all  cycle  specific  entities. 

•  A23,  Terminate  the  Unigraphics  Session,  shows  a  standard  filing  and  exit 
from  the  Unipaphics  system. 
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A-0  RFC  Software 

AO  RFC  Interface 

A1  PDES  Post  Processor 
A2  RFC  Conversion  Routines 
A21  Initialize  UQ  Model 
A22  Convert  Entities 
A23  Terminate  UQ  Session 
A221  Convert  Simple  Geometry 
A223  Convert  Cycle  Related  Entities 


A221 


A223 
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Figure  3-25.  RFC  Interface  Block  Diagram 

A  key  component  of  the  preliminary  design  was  to  produce  a  Development  Specification  for 
the  prototype  RFC  Interface.  The  RFC  Interface  Development  Specification  (Cl  DS560240011U) 
described  the  functions,  performance,  environment,  interfaces  and  design  requirements  for  the 
RFC  Interface.  It  detailed  the  requirements  satisfied,  was  compatible  with  the  System  Design 
Specification  design  approach,  and  was  traceable  back  to  the  System  Requirements  Document. 
The  document  described  the  RFC  Interface  in  terms  of:  functional  characteristics,  performance 
characteristics,  physical  characteristics,  interface  characteristics,  and  design  constraints. 

Section  3  of  the  RFC  Development  Specification  described  the  existing  system  environment 
and  architecture  and  documented  the  to-be  system  developed  for  the  end-of-contract  demonstra¬ 
tion.  Section  3.2  described  the  hardware  and  software  requirements;  Section  3.3  detailed  the 
functional  requirements;  and  Section  3.6  described  the  data  requirements  of  the  to-be  system. 

3-93 


itnos/3 


Cl  FTR560240001U 
September  1989 


3.3. 1.2  RFC  Interface  Detail  Design 

The  detail  design  work  on  the  RFC  interrace  led  to  the  production  of  a  Product 
Specification  and  a  Unit  Test  Plan  for  demonstrating  the  effectiveness  of  the  prototype  RFC 
Interface. 

A  Product  Specification  was  produced  for  each  Development  Specification.  There  were  two 
versions  of  the  Product  Specification:  the  “As-designed”  and  the  “As-built”.  The  “As-designed” 
Product  Specification  and  “As-built”  Product  Specification  differed  only  in  that  the  “As-built” 
Product  Specification  included  all  of  the  changes  made  to  the  “As-designed”  version  throughout 
the  remainder  of  the  project.  Based  on  each  Development  Specification,  the  “As-designed” 
Product  Specification  established  the  design  of  the  configuration  item  (RFC  or  IBIS)  including 
structure,  functions,  language,  data  base,  individual  components,  interfaces  and  quality 
assurance  provisions,  as  applicable. 

A  Ui.  Test  Plan  was  also  produced  for  each  Development  Specification.  The  Unit  Test 
Plan  was  tra  '<ble  to  each  requirement  as  stated  in  the  Development  Specification.  The  Unit 
Test  Plan  assu  s^  that  each  requirement  stated  in  the  Development  Specification  would  be 
adequately  validated,  and  that  the  data  generated  during  demonstrations  would  verify  that  the 
performance  objectives  were  met. 

3.3.1.2.1  RFC  interface  Product  Specification 

The  GMAP-to-RFC  “As-designed”  Product  Specification  (Cl  PS56024(X)11U)  was  pub¬ 
lished  in  December  1987.  The  “As-built”  Product  Specification  (Cl  PS560240012U)  was 
published  in  February  1989.  The  main  body  of  the  RFC  Product  Specification  discussed  the 
processing,  input  and  output  parameters,  and  presented  code  for  each  of  the  routines  in  the  RFC 
Interface. 

3.3. 1.2.2  RFC  Interface  Unit  Test  Plan 

The  GMAP-to-RFC  Unit  Test  Plan  (Cl  UTP56024()011U)  was  published  in  December 
1987.  The  Unit  Test  Plan  assured  that  each  requirement  stated  in  the  RFC  Development 
Specification  would  be  adequately  validated,  and  that  the  data  generated  during  demonstrations 
would  verify  that  the  performance  objectives  were  met.  The  RFC  Interface  software  was  tested  at 
four  levels:  Module,  Program,  Acceptance,  and  System  Integration  testing.  Figure  3-26  indicates 
the  testing  level  relationship.  The  RFC  Unit  Test  Plan  discussed  each  of  these  testing  levels  in 
detail. 


Although  there  were  no  specific  performance  requirements  for  the  RFC  Interface,  the 
modular  design  and  software  quality  assurance  procedures  used  in  software  development  ensured 
that  it  was  efficient  and  reliable.  Therefore,  there  were  no  explicit  performance  tests  to  be 
performed.  Plans  called  for  producing  problem  reports,  test  logs,  and  test  results  during  testing  to 
assist  in  generating  the  Unit  Test  Report. 
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1  •  Model  Testing  (With  Representative  Entities) 

2  -  Progratn  Testing  (With  Representative  ModeO 

3  •  Acceptance  Testing  (With  Pratt  &  Whitney  GMAP  Model  at  McOonnel  Oouglaa) 

4  •  System  integration  Testing  (With  Pran  &  Whitney  GMAP  Model  at  Systems  Research  Laboratories) 


FDA  366292 

Figure  3*26.  RFC  Interface  Testing  Level  Relationships 

3.3.2  Establish  Interface  to  Blade  Inspection 

The  IBIS  is  a  highly  automated  inspection  system  at  the  San  Antonio  Air  logistics  Center. 
The  GMAP-to-IBIS  Interface,  built  by  ITI,  provides  FDD  to  the  Inspection  Plan  Generation 
Subsystem  (IPGS)  of  IBIS.  It  facilitates  the  inspection  of  in-service  engine  compressor  blades  for 
surface  anomalies  using  fluorescent  penetrant  inspection. 

3.3.2.1  IBIS  Interface  Preliminary  Design 

The  GMAP-to-IBIS  Interface  was  designed  to  perform  the  following  tasks. 

•  Derive  an  IBIS-compatible,  bi-cubic  patch  surface  representation  of  the  blade 
from  the  Non-Uniform  Rational  B-spline  (NURB)  surface  representation 
contained  in  tha  GMAP  model 

•  Extract  the  flaw  criteria  and  inspection  zone  information  from  the  GMAP 
model  and  make  them  available  to  the  IPGS. 
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The  IBIS  Interface  then  provided  two  types  of  information  to  the  IPGS  using  a  GMAP 
blade  model  as  input: 

•  External  surface  data  needed  to  inspect  the  blade  surfaces  correctly 

•  Inspection  criteria  information  needed  to  determine  the  disposition  of  the 
blade  after  inspection. 

Blade  geometry  was  provided  to  IBIS  in  an  electronic,  IPGS-native  format.  Flaw  criteria 
and  inspection  zone  information  was  provided  in  an  electronic,  textual  format. 

A  schematic  of  the  IBIS  Interface  architecture  is  illustrated  in  Figure  3-27.  A  hierarchical 
representation  of  the  IBIS  Interface  is  shown  in  Figure  3-28  as  a  high  level  IDEFO  functional 
model. 

PDDI 

Specs 


pool  MAS 


Context:  GMAP-to-IBIS  interlace  Software 

Viewpoint:  Development  Personnel 
Purpose:  Identify  the  Interface  Requirements 

of  the  QMAP-to-IBIS  Interface 

FOA  341295 

Figure  3-27.  GMAP-to-IBIS  Interface  Architecture 
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Figure  3-28.  EBIS  Interface  Block  Diagram 


A-0,  the  GMAP  to  IBIS  Interface,  converte  the  GMAP  compreasor  blade  model  from  the 
exchange  format  into  an  IBIS  specific  data  format  file,  and  an  IBIS  inspection  data  file.  This  is  a 
top  system  view.  Component  systems  follow. 

•  AO,  the  GMAP  to  IBIS  Interface,  consists  of  the  GMAP  System  Translator 
and  the  Interface  Conversion  Routines. 

•  Al,  the  GMAP  System  Translator,  converts  the  model  from  the  exchange 
format  into  a  memory  resident,  random  access  working  form. 

•  A2,  the  Interface  Conversion  Routines,  converts  the  working  form  into  IBIS 
format. 

•  A21,  Convert  Surfaces,  consists  of  two  functions.  The  first,  converts  all 
rational  b-spline  surfaces  into  parametric  spline  surfaces.  The  second, 
converts  the  parametric  spline  surfaces  into  bi-cubic  patch  surfaces. 

•  A22,  Convert  Inspection  Data,  consists  of  two  working  form  to  inspection 
informr-tfon  conversion  procedures.  The  first  converts  all  flaw  criteria 
information.  The  second  deals  with  the  conversion  of  all  inspection  zone 
definition  data  in  the  model. 

As  with  the  RFC  Interface,  a  key  effort  in  the  preliminary  design  was  to  pioduce  a 
Development  Specification  for  the  IBIS  Interface  prototype. 
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The  IBIS  Interface  Development  Specification  (Cl  DS560240021U)  described  the  func¬ 
tions,  performance,  environment,  interfaces  and  design  requirements  for  the  IBIS  Interface  in 
much  the  same  manner  as  the  RFC  Development  Specification. 

Section  3  of  the  IBIS  Development  Specification  described  the  to-be  system  developed  for 
the  erd-of-contract  demonstration.  Section  3.1.2  defined  the  GMAP-to-IBIS  Interface  require¬ 
ments.  This  Interface  actually  consisted  of  three  separate  interfaces.  They  were: 

1.  GMAP  Product  Model 

2.  MAS  and  N/VI 

3.  IPGS. 

The  detailed  functional  requirements  for  these  interfaces  are  contained  in  Section  3.2  of  the 
IBIS  Development  Specification.  That  section  also  discussed  the  required  inputs,  processing,  and 
outputs. 

3.3.2.2  lEiS  Interface  Detail  Design 

As  with  the  RFC  Interface,  the  detail  design  work  on  the  IBIS  Interface  led  to  the 
production  of  a  Product  Specification  and  a  Unit  Test  Plan  for  demonstrating  the  effectiveness 
of  the  prototype  IBIS  Interface. 

3.3.2.2.1  IBIS  Interface  Product  Specification 

This  specification  established  the  design  of  the  GMAP-to-IBIS  Interface.  The  GMAP  to- 
IBIS  “As-designed”  Product  Specification  (Cl  PS560240021U)  was  published  in  March  1988. 
The  “As-built”  version  (Cl  PS560240022U)  was  published  in  February  1989.  With  the  use  of 
functional  flow  diagrams,  the  main  body  of  the  Product  Specification  discussed  the  detailed 
functional  requirements  of  the  GMAP-to-IBIS  Interface  including  input,  processing,  and  output 
requirements. 

The  Product  Specification  also  included  descriptions  of  four  distinct  logical  modules 
comprising  the  interface,  each  consisting  of  a  niunber  of  routines: 

1.  GMAP  to  IBIS  Interface  Control  Module 

2.  GMAP  System  Translator 

3.  working  form  to  IBIS  Specific  Data  Format  File  Conversion  Module 

4.  working  form  to  IBIS  Inspection  Data  File  Conversion  Module. 

3.3.2.2.2  IBIS  Interface  Unit  Test  Plan 

The  GMAP-to-IBIS  Interface  Unit  Test  Plan  (Cl  UTP56024(X)21U)  assured  that  the 
performance  objectives  stated  in  the  Development  Specification  would  be  adequately  validated. 
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The  GMAP-to-IBIS  Interface  software  was  tested  at  four  levels: 

1.  Module  (subprogram)  testing 

2.  Program  testing 

3.  Acceptance  testing 

4.  System  integration  testing. 


The  first  three  levels  verified  the  GMAP-to-IBIS  Interface.  The  fourth  level  verified  the 
overall  GMAP  concepts.  Figure  3-29  illustrates  the  relationship  of  the  testing  levels. 


3  -  Acceptance  Testing  -  With  Pratt  &  Whitney  GMAP  Model  at  ITl 

4  -  System  Integration  Testing  -  With  Pratt  &  Whitney  GMAP  Model  at  SA-ALC 

(GMAP-to-IBIS  Interlace  Demo) 
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Figure  3-29.  IBIS  Testing  Level  Relationships 

3.4  Task  4  —  Build  and  Integrate  the  Applications  Interface 

Under  Task  4,  GMAP  software  was  constructed  and  the  function,  performance,  and 
integration  of  the  system  was  verified  in  accordance  with  the  system  and  unit  test  plans 
established  in  Tasks  2  and  3.  Applicable  manuals  were  produced  for  the  installation  and 
operation  of  the  system. 
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3.4.1  Construct  Software 

The  foundation  of  the  GMAP  system  was  the  software  originally  built  and  tested  under  the 
PDDI  program  conducted  by  McDonnell  Douglas.  This  includ^  the  MAS,  the  Sjrstem 
Translator,  as  well  as  the  data  dictionary  and  PASCAL  include  files.  Task  2  identified  the 
enhancements  necessary  to  the  basic  PDDI  software  for  the  more  complex  parts  in  GMAP  and  to 
encompass  the  entire  product  life  cycle.  Summarized  below  is  the  software  that  comprises  the 
GMAP  system.  Figure  3-30  illustrates  the  relationship  of  this  software  in  a  diagram  of  the 
GMAP  system  architecture.  Table  3-23  lists  the  systems  on  which  the  software  components  were 
implemented  and  the  version  numbers  of  each. 

•  System  Translator  —  A  software  mechanism  used  for  communicating  data 
between  dissimilar  systems  initially  developed  under  PDDI  and  enhanced  in 
GMAP. 

•  Name/Value  Interface  added  in  GMAP  to  the  PDDI  MAS  —  The  MAS  is  a  set 

t. '  routines  that  allow  access  to  product  models  for  creation,  modification, 
dei.  tion,  and  navigation  at  the  entity  level.  The  N/VI  is  a  set  of  PASCAL 
subroc  tines  that  help  query  the  PDD  model  about  entity  attributes.  It  firees 
the  application  programs  from  the  need  to  know  the  physical  location  of  an 
attribute  for  an  entity.  It  provides  access  at  the  attribute  level. 

•  Schema  Manager  —  One  of  two  new  components  developed  in  GMAP,  it 
creates  the  data  dictionary  and  PASCAL  include  files.  These  are  the  physical 
files  that  define  the  data  schema  to  the  system  components  and  applications. 

•  PDD  Editor  —  The  second  of  two  new  components  developed  in  GMAP,  it 
adds  PDD  such  as  geometry,  tolerances,  form  features,  administrative  and 
assembly  data,  etc.  to  demonstration  models  for  each  application  from  Data 
Dictionary  definitions. 

•  Data  Dictionary  —  A  listing  of  all  the  possible  entity  types  and  attributes  that 
could  occur  in  any  model  including  their  names,  data  types,  size,  attribute 
displacements,  and  usage. 

•  PASCAL  Include  Files  —  Representations  of  the  Data  Dictionary  for  use  in 
PASCAL  application  programs.  The  Data  Dictionary  is  used  primarily  for 
FORTRAN  programs. 

•  Interfaces  to  the  Air  Force’s  RPC  and  IBIS  at  the  San  Antonio  Air  Logistics 
Center. 

3.4.2  Construct  Models 

To  complete  the  GMAP  s}rstem,  testing  was  conducted  according  to  the  System  Test  Plan 
with  actual  complete  PDD  models. 
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Figure  3-30.  GMAP  System  Architecture 

Commercial  modeling  systems  in  use  at  Pratt  &  Whitney  were  used  for  the  initial  geometry 
and  topology  creation  of  the  GMAP  POD  models.  This  included  the  use  of  the  IBM  CAEDS,  the 
Computervision  CADDS4X,  and  the  MCS  ANVIL  4000  systems.  Additional  POD,  such  as 
tolerances,  nonshape,  form  features,  and  so  on  were  added  by  the  POD  Editor  where  required. 
For  example,  Figure  3-31  illustrates  the  process  whereby  the  complete  turbine  blade  model  was 
populated  by  use  of  POD  Editor  interaction  with  the  Data  Dictionary.  Those  models  are 
summarized  in  the  paragraphs  that  follow.  More  comprehensive  descriptions  can  be  found  in  the 
GMAP  Demonstration  Model  Description  document  (TTD560240001U). 

3.4.2.1  Disk  Design  Model 

The  Disk  Design  model  was  created  on  a  SUN -based  Computervision  CADDS4X 
CAD /CAM  system  at  Pratt  &  Whitney.  This  model  was  generated  starting  with  a  cross-section 
of  the  disk  shape.  The  disk  was  a  turned  part  that  was  partially  represented  by  a  BOR  object.  A 
BOR  is  a  complete  topological  representation  of  a  2-0  turned  part.  A  full  representation  requires 
bolt  holes,  scallops,  and  other  nontumed  features  to  be  represented  as  3-D  features. 
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TABLE  3-23. 

GMAP  SOFTWARE  PLATFORM  MATRIX 


Sottwsre 

Operating 

Syetem 

pool  Version 

GMAP 

Version 

Original 

Extension 

Schema  Manager 

IBM/MVS 

3.0 

4.G 

EBM/CMS 

4.0 

Model  Access 

IBM/MVS 

9.0 

3.0 

4.0 

Software 

IBM/CMS 

2.0 

3.0 

4.0 

VAXA^MS 

2.0 

3.0 

4.0 

UNIX 

2.0 

N’ame/Value  Interface 

IBM/MVS 

4.0 

IBM/CMS 

4.0 

VAX/VMS 

4.0 

System  Translator 

IBM/MVS 

2.0 

3.0 

6.0 

IBM/CMS 

2.0 

3.0 

5.0 

VAX/VMS 

2.0 

3.0 

5.0 

UNDC 

2.0 

Data  Dictionary 

IBM/MVS 

2.0 

3.0 

4.0 

IBM/CMS 

2.0 

3.0 

4.0 

VAX/VMS 

2.0 

3.0 

4.0 

UNIX 

2.0 

4.0 

PASCAL  Include  Files 

IBM/MVS 

2.0 

3.0 

4.0 

IBM/CMS 

2.0 

3.0 

4.0 

VAX/VMS 

2.0 

3.0 

4.0 

PDD  Editor 

IBM/CMS 

4.0 

IBIS  Interface 

VAX/VMS 

1.0 

RFC  Interface 

VAX/VMS 

1.0 

RJQ«tt/13 


The  BOR  object  with  3-D  features,  tolerances,  and  notes  was  sufficient  information  to 
represent  the  disk  for  downstream  applications.  The  BOR  underlying  2-D  profile  was  revolved 
about  an  axis,  creating  a  full  3-D  model  for  the  applications  requiring  surfaces. 

The  disk  model  was  output  from  the  Computervision  system  as  a  GMAP  exchange  format 
file.  This  was  possible  since  the  MAS  and  System  Translator  were  ported  to  the  Computervision 
system.  In  the  the  exchange  format,  the  model  was  available  for  the  other  disk-related  GMAP 
demonstrations. 
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Figure  3-31.  FDD  Editor  Interaction  With  the  Data  Dictionary 


3.4.2.2  Process  Capabilities  Model 

The  PROCAP  model  was  a  FlOO  Ist-stage  disk.  This  model  contained  geometry,  BOR 
topology,  form  features,  tolerances  and  Administrative  information.  Geometrically,  it  was 
described  by  a  contiguous  2-D  curve  string.  Elements  of  the  curve  string  were  2-D  open  curves. 
These  curves  underlied  tr^logical  BOR  FACES  and  FACES  which  are  shape  elements. 
Tolerances  were  attached  to  FACES  via  an  topological  representation,  in  this  case,  BOR  FACES 
were  combined  in  the  PDD  Editor  and  were  designated  as  form  features,  such  as  iimer  diameters 
and  outer  diameters. 


3.4.2.3  Feature-based  N/C  and  Coordinate  Measuring  Machine  Model 

The  Feature-based  N/C  and  CMM  modri  was  a  three  dimensional  model  of  the  FlOO  Ist- 
stage  disk  counter  balance  weight  flange  consisting  of  boles  and  scallops.  The  scallops  were 
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modeled  as  3-D  DRIVEN  FEATURES  based  on  geometric  extrusions  that  were  replicated 
around  the  entire  disk  via  the  CIRCULAR-FEATUREl-PATTERN  entity.  Similarly,  the  holes 
were  modeled  as  THRU— HOLESs  that  were  replicated  around  the  (^k  via  the  CIRCU¬ 
LAR— FEATUREL-PATTERN  entity.  Toleramws  and  datums  were  also  in  the  model  for  a  CMM 
application. 

3.4.2.4  GMAP-to-RFC  Interface  Model 

The  GMAP  PDD  model  for  the  RFC  ^stem  included  a  BOR  representation  of  the  disk 
body.  This  2-D  representation  contained  geometry  and  topology  and  provided  sufficient 
information  to  produce  a  full  3-D  BOR.  Inspection  zones  for  the  RFC  system  were  also  included 
in  the  model.  Tliese  zones  had  associated  external  and  internal  flaw  criteria  required  by  the  RFC 
system.  Notes  from  the  engineering  drawing,  as  well  as  administrative  data,  were  also  included. 
These  notes  were  embodied  as  GMAP  nonshape  entities  and  included  tolerances  and  datums. 

3.4.2.5  Disk  Forging  Model 

The  Disk  Forging  model  was  built  by  Wyman  Gordan  using  ANVIL  4000  on  a  VAX 
computer  system.  The  model  was  then  modified  to  contain  nonconforming  characteristics. 
Business  data  and  other  required  technical  data  were  added  to  the  ANVIL  part  file  using 
available  ANVIL  entities,  such  as  text,  in  conjunction  with  level  assignments.  The  technical 
data,  typical  of  the  disposition  process,  included  administrative  information,  geometry,  forge 
shape,  finished  shape,  and  features. 

A  special  purpose  translator  was  used  to  translate  the  ANVIL  part  file  into  the  GMAP 
working  form.  After  creating  the  working  form,  the  model  was  translate  to  exchange  format  for 
transmittal  to  Pratt  and  Whitney. 

3.4.2.6  Parametric  Blade  Design  Model 

The  parametric  blade  design  model  was  an  FIDO  1st  stage  turbine  blade.  The  turbine  blade 
geometry  and  topology  were  built  at  Pratt  &  Whitney  in  the  CAEDS  solid  modeler  on  an  IBM 
computer.  Design  system  translators  converted  raw  design  data  firom  several  different  files  into 
CAEDS  program  file  format.  The  CAEDS  solid  model  was  run  through  the  CAEDS  SUPERTAB 
option  to  create  a  BREP  model  The  model  was  then  output  as  a  CAEDS  universal  file  which  was 
converted  into  the  GMAP  working  form  by  a  translator  written  for  this  purpose.  There,  a 
representative  sample  of  Notes,  Tolerances,  Specifications,  Datums  and  Form  features  were 
added  to  the  model  using  the  PDD  Editor  to  complete  the  model. 

It  was  impossible  to  create  one  complete  PDD  model  of  the  turbine  blade,  either  in  CAEDS 
or  the  PDD  Editor,  because  of  model  size.  If  the  complete  turbine  blade  model  were  built,  it 
would  need  approximately  46M  of  memory  and  approximately  78M  of  disk  space  for  storage,  of 
which  98  percent  was  geometric  entities.  Therefore,  this  model  was  built  in  four  pieces  and 
redundant  PDD  were  omitted.  The  four  models  were:  airfoil  with  inteiual  cooling  features, 
platform,  shank,  and  attachment. 

A  CAEDS  restriction  on  the  number  of  facets  in  a  solid  limited  our  ability  to  model  the 
entire  part.  This  restriction  prohibited  the  addition  of  much  of  the  detailed  geometric  entities 
such  as  fillets,  trip  strips  (extrusions),  and  cooling  holes. 
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3.4.2.7  Casting  Tooling  Electrical  Discharge  Machining  Electrode  Model 

The  EDM  electrode  model  was  a  S-D  model  consisting  primarily  of  free  form  curves  and 
surfaces.  Geometric  entities  in  the  model  were  combined  via  the  explicit  feature  entity  to 
communicate  implication  specific  features.  Ribs,  airfoil  parting  surfaces,  and  tr^  strips  are 
examples  of  applications  features.  The  model  consisted  of  five  application  specific  features: 
airfoil  upper  surface,  eirfoil  parting  surface,  ribs,  trm  strips,  and  tooling  base. 

3.4.2.8  GMAP-to-IBlS  Interface  Model 

The  IBIS  model  consisted  of  an  accurate  and  complete  description  of  the  blade  external 
stufaces.  These  were  represented  by  3-D  free  form  BREP  surfaces.  The  inspection  zones  and 
related  geometry  were  also  included  in  the  model.  Inspection  criteria,  surface  flaw  criteria  and 
surface  flaw  limits  in  the  model  were  associated  to  inspection  zones  and,  therefore,  related  blade 
geometry. 

3.4.2.9  Be '8  N/C  Programming  Model 

The  Boss  N/C  model  was  a  model  of  a  jet  engine  case  plumbing  attachment  boss.  This  is 
the  same  model  used  in  the  Boss  inspection  demonstration  with  additional  form  features  to 
enable  N/C  machining.  The  complete  product  definition  of  the  model  was  created  in  the  PDD 
Editor.  Geometry  and  topology  were  represented  using  the  GMAP  BREP  representation.  The 
geometry  and  topology  element  were  grouped  under  form  features.  Attached  to  the  form  features, 
geometry  and  topology  were  the  datums  and  tolerances. 

The  product  model  working  form  was  built  at  Pratt  &  Whitney  and  translated  into 
exchange  format.  It  was  converted  back  to  working  form  at  Automation  Technology  Products 
(ATP). 

The  data  from  the  product  model  was  then  used  at  ATP  to  build  a  CIMPLEX  model,  from 
which  N/C  programs  for  the  case  boss  were  generated.  The  part  was  subsequently  machined  at 
Ingersoll 

3.4.2.10  Boss  Inspection  Model 

The  Boss  Inspection  model  was  a  model  of  the  engine  case  plumbing  attachment  boss.  The 
complete  product  definition  model  of  the  boss  was  created  in  the  PDD  Editor  at  Pratt  & 
Whitney.  Geometry  and  topology  were  represented  using  the  GMAP  BREP  representation.  The 
geometry  and  topology  elements  were  grouped  under  the  GMAP  form  features.  The  datums  and 
tolerances  are  attached  to  the  form  features,  geometry  and  topology. 

3.4.3  Test  System 

Testing  of  the  individual  GMAP  system  components  as  well  as  the  integrated  GMAP 
system  through  application  demonstrations  is  described  in  detail  in  the  GMAP  System  Test 
Report  (Cl  STR560240001U).  The  System  Test  Report  discusses  the  Test  Approach,  Test 
Objective,  Test  Environment,  Methods  to  Determine  Quality  of  Results,  and  fin^y,  the  Test 
Results  for  each  component  test  and  application  demonstration. 
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3.4.3.1  New/Enhanced  System  Components 

In  general,  testing  of  the  Schema  Manager  verified  functionality  for  the  following 
capabilities: 

•  Interactive  entity  creation 

•  Interactive  entity  update 

•  Interactive  entity  review 

•  Generation  of  files/reports  from  entity  definitions: 

—  Conceptual  Schema  report 
—  PASCAL  Include  files 
—  Run-time  subschema  file 
—  Data  Dictionary  file 
—  File  and  retrieval  of  schema  master  file. 

The  following  Schema  Manager  functions,  developed  under  the  PDDl  Extension  project 
effort  wer*.  also  verified: 

•  Bate’’  interface 

•  Model  query  utility. 

The  majority  of  the  MAS  was  developed  and  tested  in  the  original  PDDI  Project.  These 
tests  are  documented  in  the  PDDI  System  Test  Report  (STR560130000)  dated  30  July  1985. 
Additional  testing  was  performed  only  to  verify  fixes  and  provisions  for  the  N/VI. 

The  N/VI  provides  the  following  capabilities: 

•  DIRECT  QUERY  SUBPROGRAMS,  called  by  application  programs  to  query 
an  attribute  value  for  a  specified  entity  (including  an  attribute  for  a 
constituent  entity) 

•  DIRECT  STORE  SUBPROGRAMS,  called  by  application  programs  to 
replace  an  attribute  value  for  a  specified  entity  (including  an  attribute  for  a 
constituent  entity) 

•  PROCEDURAL  QUERY  SUBPROGRAMS,  called  by  application  programs 
that  require  a  list  of  entities  with  a  specified  attribute  value  (including  an 
attribute  for  a  constituent  entity). 

Testing  of  the  N/VI  followed  the  criteria  established  in  the  System  Test  Plan  and  the  N/VI 
Unit  Test  Plan  appended  to  the  System  Test  Plan.  The  detailed  test  procedures  consisted  of  a 
computer  program  to  perform  the  required  steps.  The  specific  data  entered,  the  expected  results, 
and  the  actual  results  were  documented  in  the  N/VI  test  log.  Any  deviations  found  were  entered 
in  a  discrepancy  report  and  corrected.  The  test  results  verified  functionality  for  the  three 
capabilities. 

The  original  PDDI  System  Test  Plan  was  slightly  modified  and  used  in  Acceptance  Testing 
(Phase  3)  of  the  System  Translator  to  ensure  that  the  GMAP  Translator  was  tested  under  the 
same  criteria  as  the  original  PDDI  Translator.  These  tests  were  successfully  completed. 
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In  addition,  the  GMAP  System  Translator  (Version  4)  was  used  in  the  application 
demonstrations.  Subsequent  to  the  completion  of  the  application  demonstrations,  the  System 
Transistor  was  modified  to  further  enhance  its  performance.  This  new  Version  5  System 
Translator  was  delivered  under  the  contract 

The  functionality  of  this  new  System  Translator  was  verified  through  the  use  of  a  series  of 
round-robin  tests.  Model  verification  was  also  performed  using  the  Version  5  Translator.  The 
in  creased  performance  of  this  Translator  allowed  a  large  number  of  models  to  be  processed.  The 
completeness  and  accuracy  of  the  translation  was  verified  with  a  utility  devel(4>ed  for  this 

'.esting. 

Informal  testing  and  debugging  of  the  PDD  Editor  occurred  jointly  between  Pratt  & 
Whitney  and  ITI  during  PDD  model  building.  Formal  testing  and  debugging  of  the  PDD  Editor 
were  performed  according  to  a  test  plan  specific  to  the  Editor.  The  results  of  the  PDD  Editor 
testing  showed  that  all  entities  were  created,  modified,  and/or  maintained  as  per  the  GMAP 
schema  specification. 

3.4.3.2  Applications 

The  objective  of  the  test  applications  was  to  verify  the  fimctionality  of  the  technology 
developed  under  GMAP  in  actual  product  life  cycle  situations.  Several  applications  were  selected 
ti>  address  each  of  the  parts  of  concern:  blades,  disks,  plumbing  attachment  bosses,  and  parts 
initially  used  in  the  PDDI  program.  Demonstrations  of  these  applications  were  videotaped  to 
provide  permanent  documentation.  These  tapes  can  be  obtained  from  the  Air  Force  ICAM 
Library. 


3.4.3.2.1  Parametric  Cooled  Turbine  Blade 

This  application  focused  on  an  Fl(X)  1st  stage  turbine  blade  such  as  that  described  in 
paragraph  3.4.2.6  and  shown  in  Figure  3-32.  Using  the  CAEDS  solid  modeler,  an  improved  design 
method  for  this  blade  was  demonstrated  by  directly  translating  design  data,  parametrically 
generating  and  modifying  geometry,  and  finally,  by  preparing  a  complete  part  model  through  use 
of  the  PDD  Editor.  The  resulting  PDD  model,  which  contained  geometric  and  nonshape  data, 
was  a  source  for  subsequent  GMAP  blade  life  cycle  application  demonstrations.  The  procedure  is 
illustrated  in  Figure  3-33. 


There  were  four  specific  objectives  in  blade  design  procedure: 

1.  Verify  the  design  system  translators  contained  the  appropriate  source  data 
along  with  the  appropriate  geometric  construction  commands 

2.  Verify  that  the  CAEDS  solid  model  was  geometrically  acairate 

3.  Verify  that  the  BREP  model  data  were  consistent  with  the  solid  model 

4.  Verify  that  the  PDD  model  contained  geometry  consistent  with  the  BREP 
model  and  also  to  verify  the  accuracy  and  completeness  of  the  nonshape  data 
added  by  the  PDD  editor. 
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Figure  3-32.  Internal  Design  Features  of  the  FlOO  Ist-Stage  Turbine  Blade 

The  solid  model  generated  by  CAEDS  produced  results  that  were  within  the  limits 
eipected.  The  horizontal  cuts  at  defining  sections  produced  results  within  0.0001  inch.  The 
horizontal  cuts  at  nonkey  locations  showed  a  maximum  difference  of  0.0003  inch.  This  greater 
variation  was  somewhat  expected  due  to  inherent  splining  differences.  These  horizontal  cuts  also 
showed  that  cooling  hole  diameters  and  locations  agreed  precisely  with  the  source  data.  Vertical 
cuts  showed  that  core  rib  geometry  was  within  0.0005  inch  of  the  source  data.  The  trip  strip 
profiles  and  locations  agreed  precisely  with  the  source  data.  Verification  of  the  accuracy  and 
content  of  FDD  model  entities,  both  geometric  and  nongeometric,  was  successfully  accomplished 
using  the  FDD  Editor’s  “verify  entities”  function. 
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Figure  3-33.  Parametric  Blade  Design  Procedure 
3.4.3.2.2  Casting  Tooling 

The  Casting  Tooling  application  dealt  with  the  manufacture  and  inspection  of  an  EDM 
Electrode,  shown  in  Figures  3-34.  This  electrode  was  used  to  machine  the  core  in  a  mold  as  part 
of  the  turbine  blade  casting  process.  The  part  creates  the  complex  geometry  of  the  upper  surface 
of  the  blade  cooling  cavity.  This  was  one  of  the  most  critical  and  difficult  applications  in  the 
manufacture  of  turbine  blades. 

The  entire  casting  tooling  application  consisted  of  four  applications: 

•  Supplier  N/C  Machining.  Mold  Masters  of  Mentor,  Ohio,  a  Pratt  &  Whitney 
casting  tooling  supplier,  used  a  GMAP  model  to  machine  the  electrode, 
demonstrating  supplier  base  integration. 

•  Internal  N/C  Machining.  An  internal  Pratt  &  Whitney  group  used  the  same 
GMAP  model  to  machine  an  electrode. 

•  CMM  Inspection.  The  upper  surface  of  each  electrode  was  inspected  using  the 
GMAP  model. 
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•  Automated  Optical  Inspection.  The  electrode  ribs  and  trip  strips  were 
inspected  by  Optical  Gaging  Products  using  the  same  GMAP  model. 


The  procedure  and  design  data  used  to  create  the  turbine  blade  model  in  the  Parametric 
Cooled  Turbine  Blade  Design  demonstration  were  also  used  to  create  a  model  of  the  EDM 
electrode  in  CAEDS.  The  CAEDS  part  was  then  translated  to  working  form  using  a  CAEDS  to 
working  form  translator  written  by  ITI.  Additional  PDD  was  added  to  the  working  form  model 
using  the  PDD  Editor. 

3.4.3.2.2.1  Supplier  N/C  Electrode  Machining 

An  exchange  format  version  of  the  EDM  electrode  was  created  by  Pratt  &  Whitney  and 
sent  to  Mold  Masters,  Inc.  To  enable  Mold  Masters  to  utilize  the  model,  it  was  necessary  to 
install  the  System  Translator  on  their  Computervision  workstation.  This  allowed  the  creation  of 
a  working  form  version  of  the  model  on  Mold  Masters’  SUN/UNIX  platform.  An  application - 
specific  translator  developed  by  Pratt  &  Whitney  with  Computervision  support  was  then  used  to 
translate  the  GMAP  model  into  a  CADDS4X  model.  An  interface  diagram  of  the  application 
demonstration  is  shown  in  Figure  3-35. 
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Figure  3-35.  Supplier  N/C  Electr>Je  Machining  Domonstration  Diagram  of  Interfaces 


Qualification  tests  were  performed  to  validate  the  results  of  the  translation  process.  Once 
the  translation  process  had  been  verified,  Mold  Masters  created  N/C  programs  using  the  NURB 
curves  and  surfaces  provided  by  the  GMAP  model.  These  N/C  programs  were  used  to  machine 
the  electrode. 

The  machined  electrode  agreed  with  the  GMAP  product  model  within  typical  manufactur¬ 
ing  tolerances.  In-process  inspections  were  performed  periodically  to  control  machining  variables 
such  as  tool  wear.  The  electrode  was  also  inspected  at  process  completion  to  verify  that  it  was 
consistent  with  the  original  GMAP  product  model.  The  results  indicated  that  the  geometric 
integrity  of  the  EDM  electrode  models  was  maintained  throughout  the  modeling  and  translation 
process. 

3.4.3.2.2.2  bitemal  N/C  Electrode  Machining 

An  application  specific  translator  was  used  to  translate  the  GMAP  model  into  an  ANVIL 
4000  model.  This  application -specific  translator  made  extensive  use  of  the  Cox-deBoor  algorithm 
to  extract  points  from  the  GMAP-supplied  free  form  curves  and  surfaces.  These  points  were  then 
used  to  accurately  reconstruct  the  geometry  on  the  ANVIL  system. 

Qualification  tests  were  performed  to  validate  the  results  of  translating  the  GMAP  model  to 
an  ANVIL  4000  modeL  These  tests  veriSed  that  geometry  had  been  translated  with  sufficient 
accuracy  to  ensure  accurate  N/C  machining  the  EDM  electrode. 

Numerical  control  programs  were  developed  using  the  curves  and  surfaces  generated  by  the 
GMAP  System  Translator.  These  N/C  programs  were  used  by  an  in-house  machiriing  group  to 
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machine  an  electrode.  This  produced  An  electrode  which  agreed  with  the  GMAP  product  model 
within  typical  manufacturing  tolerances.  This  electrode  was  used  in  the  automated  inq>ection 
demonstrations. 

3.4.3.2.2.3  CMM  Inspection 

i  his  test  was  one  of  two  insp^rtions  of  the  EDM  electrodes  machined  in  the  supplier  and 
in-house  N/C  machining  demonstrations  described  above.  In  this  inspection,  a  Digital  Electronic 
Automation  (DEA)  CMM  was  tised  to  inspect  the  upper  surface  of  the  electrode. 

The  CMM  was  programmed  to  inspect  points  on  the  iq;)per  surface  of  the  electrodes  at 
vari'^us  cross  sections.  The  measured  points  were  compared  to  the  tolerance  requirements 
dictated  by  the  product  module  to  veri^  the  machined  surface  accuracy. 

Geometry,  form  feature,  and  tolerance  data  were  accessed  firom  the  working  form  model  of 
the  EDM  electrode  using  the  MAS.  This  information  was  processed  by  a  tool  and  die  inspection 
planning  prcgi^m  which  prepared  the  inspection  machine  control  data.  The  control  data 
consisted  v, '  the  electi .  de’s  datum  reference  frame,  cartesian  surface  points  on  the  surfaces  to  be 
inspected,  ccTesponding  stmace  normals,  and  tolerances. 

The  control  .'ile  was  used  by  a  generic  tool  and  die  measuring  program  to  drive  the  CMM. 
The  CMM  program  aligned  to  the  datum  system  dictated  by  the  product  definition,  moved  to 
each  nominal  surface  inspection  point,  and  probed  the  location  of  the  actual  surface.  CMM 
inspection  of  the  two  machined  electrodes  verified  that  they  were  consistent. 

3.4.3.2.2.4  Automated  Optical  Inspection 

This  demonstration  was  also  used  to  inspect  the  EDM  electrodes  machined  in  the  supplier 
and  in-house  N/C  machining  demonstrations  described  above.  An  Optical  Measuring  Machine 
(OMM),  manufactured  by  Optical  Gaging  Products  Inc.,  (OGP)  was  used  to  inspect  the  electrode 
ribs  and  trip  strips. 

The  OMM  was  programmed  to  measure  the  location,  width,  and  depth  of  the  features 
machined  into  the  electrode’s  upper  surface.  The  measurement  results  were  compared  to  the 
tolerance  requirements  dictated  by  the  product  definition  to  complete  verification  of  the 
electrode’s  accuracy. 

Geometry,  form  feature,  and  tolerance  data  were  accessed  from  the  working  form  model  of 
the  EDM  electrode  using  the  MAS.  This  information  was  processed  by  the  tool  and  die 
inspection  planning  program  which  prepared  the  inspection  machine  control  data.  The  control 
data  for  the  OMM  consisted  of  the  electrode’s  datum  reference  frame,  cartesian  surface  points  on 
the  features  to  be  ins(>ected,  corresponding  surface  normals,  and  tolerances.  The  control  data 
were  used  to  create  inspection  macros  using  the  DMIS  language.  The  DMIS  macros  were 
converted  to  the  native  control  langtiage  of  the  OMM  using  a  DMIS  postprocessor.  The  native 
langtiage  drove  the  OMM  through  the  various  alignment  and  measurement  sequences. 

3.4.3.2.3  Integrated  Blade  Inspection  System 

The  GMAP-to-IfilS  Interface  reads  an  exchange  format  file  that  describes  a  turbine  engine 
compressor  blade,  and  produces  one  or  more  output  files  that  could  be  used  in  the  IBIS  system 
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for  generating  inspection  plans  that  drive  blade  inspection  operations.  The  exchange  format  file 
is  read  and  put  into  the  working  form  by  the  System  Translator  postprocessor.  The  GMAP-to- 
IBIS  Interface  then  converts  the  working  form  into  one  or  more  IBIS  readable  files. 

Testing  was  performed  to  verify  the  Interface’s  function  and  quality  in  three  areas. 

1.  Accuracy  —  The  mathematical  correctness  of  the  entities  translated.  This  is 
very  important  because  the  results  of  mathematical  calculation  were  used  to 
drive  the  closely  toleranced  movements  of  an  inspection  robot. 

2.  Data  Structure  —  The  correct  relationships  between  data  used  to  describe 
the  blade  surfaces  and  data  used  to  describe  the  technical  order  inspection 
zones. 

3.  Destination  —  The  assignment  of  diffei-ent  data  to  the  correct  IBIS  data 
model.  Specifically,  verification  that  blade  geometry  data  and  blade  inspec* 
tion  information  reside  in  the  correct  files.  The  interpretation  and  grouping 
of  entities  related  to  blade  geometry  and  inspection  zones,  etc.  is  an 
important  function  of  the  GMAP-to-IBIS  Interface. 

The  GMAP-to-IBIS  Interface  was  tested  at  two  locations.  The  first  three  levels  of  testing, 
( Vfodule  level,  Program  level,  and  Acceptance  level)  were  accomplished  at  ITI  facilities  in 
Milford,  Ohio. 

The  Last  level  of  testing,  System  Integration  level,  was  performed  at  the  SA-ALC  in  Kelly 
Air  Force  Base,  Texas.  SA-ALC  personnel  then  used  the  IBIS  files  produced  by  the  GMAP-to- 
IBIS  Interface  to  produce  the  inspection  plan  to  inspect  the  demonstration  part. 

The  GMAP-to-IBIS  Interface  passed  all  of  the  executable  tests  and  has  proven  its  benefit 
to  the  inspection  plan  generation  process  at  the  SA-ALC. 

3.4.3.2.4  Disk  Design 

The  disk  design  application  dealt  with  the  FIDO  turbine  disk.  The  procedure  assumed  that 
most  of  the  preliminary  design  and  analysis  work  had  been  completed.  This  effort  consisted  of 
work  previously  done  with  Pratt  &  Whitney  proprietary  software  executed  on  an  IBM  3090 
mainframe  or  on  a  SUN  based  Computervision  workstation.  The  file  format  of  the  disk  design 
was  a  computerized  disk  file. 

The  computerized  disk  file  was  read  into  a  SUN  based  Computervision  CAD/CAM  83rstem 
where  a  solid  model  was  generated  to  calculate  mass  properties  such  as  center  of  gravity,  weights, 
moments  of  inertia,  volumes,  and  so  on.  A  shaded  picture  was  also  created  to  assist  in  surface 
visualization.  Based  on  this  output,  the  model  was  either  accepted  as  a  final  design,  or  modified 
and  reprocessed  through  the  above  steps. 

Once  the  final  design  had  been  accepted,  additional  drafting  data  were  added  such  as 
surface  finishes,  tolerances,  dimensions,  administrative  notes,  and  so  on.  The  PDD  database 
then  underwent  an  integrity  check  for  duplicate  entities,  diq>licate  dimensions,  missing 
dimensions,  and  adherence  to  design  standards.  This  integrity  check  was  performed  automatical- 


3-113 


tumt/i 


Cl  FTR560240001U 
September  1989 

ly  by  the  CAD/CAM  system  which  verified  the  accuracy  of  the  data  and  the  contiguity  of  the 
shape. 

The  Disk  Design  explication  demonstrated  that  design/drafting  data  on  an  existing 
CAD/CAM  system  can  be  intelligently  interpreted  and  converted  to  the  GMAP  format  for 
exchange  to  other  CAD/CAM  systems  downstream  in  the  manufacturing  process.  The  key 
element  in  this  process  was  translation  of  the  PDD  model  into  the  GMAP  working  form  model. 
The  IBM  working  form  model  was  used  in  conjunction  with  the  PDD  Editor  to  create  working 
form  models  for  the  downstream  demonstration  applications. 

3.4.3.2.5  PROcess  CAPabilities 

The  PROCAP  program  feeds  manufacturing  process  capabilities  back  to  engineering  and 
process  planning  for  use  in  intelligent  tolerancing  of  the  product.  PDD  from  the  GMAP  model 
were  specified  as  parameters  in  a  search  for  similar  part  types,  materials,  and  features.  Each 
manufacturing  operation  found  to  match  the  search  parameters  were  displayed  to  aid  the 
designer  in  tolerancing  the  disk  features.  The  display  included:  the  tolerance  specified,  the 
method  used  to  machine  the  feattire,  and  an  associated  cost  factor.  Thus,  the  PROCAP  program 
assists  the  designer  to  intelligently  tolerance  a  part. 

Unlike  any  other  application,  the  PROCAP  demonstration  ran  directly  from  the  PDD 
T'iditor,  i.e.,  the  PROCAP  system  was  called  directly  as  an  option  from  ^e  PDD  Editor. 
Application-specific  features  such  as  inner  diameters,  outer  diameters,  heights,  and  thicknesses, 
were  built  in  the  PDD  EJditor.  Other  information  for  the  PROCAP  system,  such  as  material  type 
and  specs,  were  coupled  with  the  PDD  and  communicated  to  the  PROCAP  system.  Features  to 
be  toleranced  were  identified  by  the  designer  on  a  graphics  screen.  The  interface  software 
interrogated  the  GMAP  model  and  extracted  the  necessary  data. 

3.4.3.2.6  Feature-Based  N/C  Machining  and  CMM  Inspection  of  Disk  Features 

This  application  used  form  features  as  a  basis  to  access  related  product  information  such  as 
topology,  geometry,  tolerances,  and  nonshape  data  from  the  disk  PDD  model.  This  information 
was  used  to  automatically  generate  both  N/C  and  CMM  source  programs.  The  specific  features 
were  associated  with  the  counterbalance  weight  flange  of  that  part. 

The  GMAP  PDD  model  of  the  disk  was  translated  into  the  working  form  and  further 
refined  by  adding  nongeometric  entities  to  the  model  using  the  PDD  Eklitor.  The  final  product 
model  of  the  disk  included:  administrative,  geometry,  topology,  form  features,  tolerances,  and 
nonsbape  information  in  addition  to  the  geometric  entities. 

The  disk  PDD  model  was  input  to,  and  analyzed  by,  the  Feature-based  N/C  Machining  and 
CMM  Programming  application  software  for  the  existence  of  the  target  form  features.  These 
features  were  the  key,  or  access  point,  to  the  underlying  and  associated  information  that  was 
required  by  the  N/C  and  the  CMM  programming  application. 

The  required  data  were  then  accessed,  cuid  used  to  create  the  source  programs  for  the  N/C 
machining  and  the  CMM  inspection  of  the  counterbalance  weight  flange  features.  The  N/C 
program  was  output  in  the  APT  soctrce  language.  The  CMM  program  was  output  in  the  DMIS 
source  language.  These  output  source  programs  were  postprocessed  to  create  target  machine 
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control  programs  on  the  N/C  machine  tool  and  CMM,  respectively.  The  control  programs  were 
then  used  to  machine  and  inspect  the  counterbalance  weight  flange  features  of  the  turbine  disk. 

The  GMAP  disk  POD  model  for  this  demonstration  was  verified  as  having  been  created 
exactly  as  specified.  Application  monitoring  proved  that,  for  the  selected  checks,  the  MAS  and 
N/VI  were  correctly  transferring  the  attributes  of  accessed  entities  to  the  ^q>lication  data  space 
for  application  use. 

The  source  programs  in  APT  and  DMIS  were  shown  to  be  comparable  to  the  prepared 
target  programs.  They  were  successfully  pos^irocessed  into  machine  language  executable 
programs  for  the  target  N/C  and  CMM  machine  tools.  The  postprocessed  machine  language 
programs  were  then  executed  at  their  respective  machine  tools  without  error. 

3.4.3.2.7  Disk  Forging 

This  application  focused  on  supplier  base  integration  between  Pratt  &  Whitney  and 
Wyman-Gordon  Company  of  Worcester,  Massachusetts.  Wyman-Gordon  is  a  major  supplier  of 
disk  forgings. 

The  subject  of  the  demonstration  was  a  Si^plier’s  Report  of  Nonconformance  (SRON), 
typically  used  by  suppliers  to  report  nonconformances.  Pratt  &  Whitney  used  this  SRON  to 
disposition  a  nonconforming  forging  and  to  evaluate  machining  set-up  changes  required  for  final 
part  shapo  machining.  SRONs  contain  a  variety  of  business  technical  data  which  are  closely 
associated  with  POD. 

A  typical  forging  SRON  consists  of  a  standard  form,  as  shown  in  Figure  3-36,  along  with  an 
attached  diagram  of  a  disk  cross-sectional  profile,  shown  in  Figure  3-37.  As  part  of  the 
demonstration,  Wyman-Gordon  and  Pratt  &  Whitney  agreed  to  the  si)ecific  content  of  a 
representative  SRON  which  included: 

•  Representative  business  data  elements  from  the  SRON  form 

•  Geometry,  including  forged  shajje,  finished  shape  and  banded  sbap>e 

•  Datums,  tolerances,  and  features. 


Wyman-Gordon  constructed  a  sample  disk  part  model  on  their  VAX-based  ANVIL 
CAD/CAM  system.  The  model  was  then  modified  to  contain  some  nonconforming  characteris¬ 
tics.  Business  and  other  required  technical  data  were  added  to  the  ANVIL  part  file  using 
available  ANVIL  entities,  such  as  text,  in  conjunction  with  level  assignments.  The  technical 
data,  typical  of  the  disp>ositioning  process,  included  administrative  information,  geometry,  forged 
shape,  finished  shai>e,  and  features. 

The  primary  objective  of  this  application  was  to  demonstrate  the  feedback  of  process  data 
closely  related  to  the  product  definition  from  a  downstream  life  cycle  function  within  a  stipplier’s 
facility  to  the  contractor.  A  secondary  test  objective  was  to  verify  data  exchange  across  the 
dissimilar  hardware  platforms  employed  between  the  contractor  and  the  supplier. 
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Figure  3-36.  SRON  Form 
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Figure  3-37.  SRON  Diagram  of  a  Disk  Profile 

The  completed  SRON/product  definition  model  was  translated  from  the  ANVIL  database 
to  exchange  format  using  GMAP  system  component  software  and  transmitted  to  Pratt  & 
Whitney.  Pratt  &  Whitney  converted  the  exchange  format  to  a  working  form  model  using  the 
System  Translator.  This  model  was  next  translated  to  a  representation  used  by  Pratt  & 
Whitney’s  prototype  dispositioning  software. 

Testing  of  each  component  showed  successful  transfer  of  the  disk  PDD  model  between  the 
supplier  and  Pratt  &  WUtney  using  the  GMAP  system  software.  The  qjplication  translator 
provided  the  correct  transfer  of  model  entities  to  the  native  representation  used  by  the 
dispositioning  software. 

3.4.3.2.8  GMAP-to-RFC  interface 

The  RFC  Interface  reads  an  exchange  format  file  that  describes  a  turbine  engine  disk,  and 
produces  one  or  more  Unigrr^ihics  parts  that  are  to  be  used  in  the  RFC  system  for  generating 
scan  plans  that  drive  disk  inspection  operations.  The  exchange  format  file  is  read  and  put  into 
the  working  form  by  the  GMAP  System  Translator’s  postprocessor.  The  RFC  Interface  converts 
the  working  form  into  one  or  more  Unigraphics  parts  and  flaw  criteria  limits  file.  The  RFC 
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Interface  software  can  be  run  interactively  from  a  nongraphics  terminal,  or  a  grqihics  terminal 
emulating  a  nongraphics  terminal,  or  as  a  batch  process. 

Testing  was  performed  to  verify  the  interface’s  function  and  quality  in  same  three  areas  as 
the  IBIS  Interface:  accuracy,  data  structure,  destination. 

RFC  Interface  testing  was  completed  at  two  locations.  The  first  three  levels  of  testing, 
(module,  program,  and  acceptance)  were  performed  at  MCAIR  facilities  in  St  Louis,  Missouri. 

System  Integration  level  testing  was  performed  at  the  Systems  Research  Laboratories 
facilities  in  Dayton,  Ohio.  Systems  Research  Laboratories  used  the  Unigraphics  parts  produced 
by  the  RFC  Interface  to  generate  the  scan  plan  and  to  inspect  the  demonstration  part 

The  RFC  Interface  passed  all  speciHed  tests  and  has  proven  its  benefit  to  the  inq>ection 
plan  generation  process. 

3.4.3.2.9  Boss  Inspection 

The  EngL  e  Case  Boss  Inspection  application  was  jointly  conducted  by  Pratt  &  Whitney 
and  the  Departn.“nt  of  Mechanical  Engineering  at  RPI,  in  Troy,  New  York.  The  primary 
objective  of  the  boss  programming  demonstration  was  to  show  GMAP  support  of  more  typic^ 
industrial  parts  than  turbine  blades  and  disks.  The  demonstration  part  was  the  plumbing 
attachment  boss  from  a  turbine  engine  diffuser  case.  The  boss  had  shape  and  tolerance 
constraints  typical  of  a  broad  range  of  mechanical  parts. 

A  geometric  model  of  a  plumbing  attachment  boss  on  a  diffuser  case,  similar  to  that  shown 
in  Figure  3-38,  was  created  at  Pratt  &  Whitney  using  a  BREP  solids  modeler. 


Figure  3-38.  Sample  Boss  Part 
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A  PDD  model  of  the  boss  was  created  as  described  in  3.4.2.10.  Then,  an  exchange  file  of  the 
boss  PDD  model  was  created  using  the  System  Translator.  The  System  Translator  ettcoded  the 
PDD  entities  into  the  exchange  file  sequential  format.  A  magnetic  tape  of  the  exchange  file  was 
produced  and  transmitted  to  the  RPI  computer  system. 

RPI  created  an  inspection  plan  for  the  boss  detail  in  the  DMIS  language  syntax.  A  DMIS 
pof.qjrocessor  supplied  by  DEA  was  used  to  postprocess  the  DMIS  program  into  the  CMM’s 
language.  Finally,  the  part  program  for  the  b^  detail  was  run  on  tlto  DEA  CMM  at  Pratt  & 
ViTiitney.  The  GMAP  system  software  worked  extremely  well  in  suiqwrt  of  data  exchange  and 


3.4.3.2.10  Boss  N/C  Programming 

The  Case  Boss  N/C  Programming  ^>plication  was  jointly  conducted  by  Pratt  &  Whitney, 
Automation  Technology  Products,  and  IngersoU  Milling  Mach^  Coiiq>any.  This  demonstration 
used  GMAP  components  to  build  and  transfer  a  product  model  of  a  plumbing  attachment  boss. 
The  starting  point  for  the  demonstration  was  a  model  of  the  boss  defined  in  the  Express 
language.  Data  in  the  model  were  gathered  from  an  engine  blueprint.  The  model  was 
subsequently  used  to  generate  and  verify  N/C  programs  for  machining  the  boss. 


Two  aspects  of  GMAP  were  evaluated  in  this  demonstration:  GMAP  software  and  the 
f'rMAP  schema.  The  GMAP  software  components  tested  were  the  PDD  Editor,  the  System 
Translator,  and  the  MAS.  The  PDD  Editor  created  the  product  model  of  the  case  boss.  The 
System  Translator  converted  the  working  form  model  to  an  exchange  file,  and  converted  the 
exchange  file  back  to  working  form.  The  MAS  extracted  the  product  data  from  the  working  form 
for  conversion  to  the  appl'^cicn’s  internal  format. 


The  procedure  was  a  success:  the  GMAP  schema’s  representation  covered  all  product  data 
needed  for  automated  N/C  generation,  and  the  GMAP  software  facUitated  effective  creation  of 
the  boss  product  model  and  communication  of  the  product  definition  data  to  the  application. 

3.4.3.2.11  Display  Query  VAX  Working  Form 

The  Display  Query  system  was  an  application  developed  by  MCAIR  on  the  PDDI  program 
to  verify  data  transfer  of  a  sheet  metal  rib  model  between  two  different  computer  systems.  This 
system  used  graphics  display  and  user  query  to  verify  that  complete  PDD  were  transferred  from 
the  IBM  part  model  database  to  the  VAX  working  form.  It  interacted  directly  with  the  working 
form  on  the  VAX  using  the  MAS. 

The  primary  objective  of  this  demonstration  was  to  verify  that  the  MAS  and  System 
Translator,  enhanced  for  GMAP,  operated  in  conjunction  with  the  original  demonstration 
software  and  the  PDDI  schema  mo^l  of  the  Sheet  Metal  Rib. 


The  new  Version  5  translator  was  used  in  this  redemorutration.  The  translation  portion  of 
the  demonstration  was  successfiiUy  completed  in  four  minutes  compared  to  one  hour  in  the 
original  PDDI  demonstration. 


Correlation  of  the  displayed  sheet  metal  rib  flat  pattern  with  the  wireframe  part  was 
established  by  visual  comparison  of  general  profiles  and  features,  showing  that  the  original 
functionality  and  integrity  of  the  PDDI  software  had  been  maintained. 
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3.4.3.2.12  Classification  and  Coding 

The  PDDI  Classification  and  Coding  System  was  another  application  developed  by  MCAIR 
to  semi-automatically  generate  the  complete  part  class  code  associated  with  a  part  A  pmrtion  of 
this  code  was  automatically  generated  from  the  interrogation  of  particular  entities  within  the 
model,  with  the  remainder  of  the  positions  created  by  a  process  platmer  via  interactive  menus. 

The  primary  objective  of  this  demonstration  was  the  same  as  that  of  the  Display  Query 
demonstration:  to  verify  that  the  enhanced  MAS  and  System  Translator  operated  in  conjunction 
with  the  original  demonstration  software  and  the  PDDI  schema  model  of  the  sheet  metal  rib. 

Correlation  of  the  flat  pattern  with  the  wire  frame  part  was  established  by  visual 
comparison  of  general  profiles  and  features  and  by  light  pen  interrogation  of  hole  sizes  and 
positions. 

This  demonstration  showed  the  ability  of  the  GMAP/PDDI  system  to  support  product 
definitions  of  parts  other  than  GMAP  schema  based  blades  and  disks. 

3.4.4  Produce  Manuals 

The  System  Components  Operator's  Manual  (Cl  OM560240001U),  the  Schema  Manager 
User’s  Manual  (Cl  UM560240011U),  the  System  Translator  User’s  Manual  (Cl 
UM560240021U),  the  Model  Access  Software  User  Manual  (Cl  56024()031U),  and  the  PDD 
Editor  User’s  Manual  (Cl  560240041U)  were  prepared  to  document  the  installation  and  use  of 
the  GMAP  software. 

The  System  Components  Operator’s  Manual  was  validated  by  a  MCAIR  engineering 
employee  with  no  previous  experience  with  GMAP.  The  employee  was  given  a  copy  of  the 
Operator’s  Manual  and  tapes  of  the  GMAP  software  (IBM  and  VAX  versions)  to  be  installed  on 
respective  equipment.  The  software  was  successfully  loaded  on  an  IBM  370  mainframe 
(MVS  OS/VS2)  and  on  a  DEC/VAX  11/780  computer  by  following  the  procedures  in  the 
Operator’s  Manual.  The  installation  procedures  were  modified  in  a  few  areas  for  clarification. 
These  modifications  were  reflected  in  the  Operators  Manual. 

The  MAS  User’s  Manual  was  validated  through  extensive  use  during  enhancement,  testing, 
and  familiarization  phases  of  the  GMAP  by  various  personnel  at  MCAIR,  Pratt  &  Whitney  and 
at  m.  N/VI  sections  of  the  manual  were  used  at  MCAIR  during  familiarization  and  testing. 

The  Schema  Manager  User’s  Manual  and  the  PDD  Editor  User’s  Manual  were  validated 
during  use  in  the  testing  phases  of  the  software.  The  System  Translator  User’s  Manual  was 
validated  during  testing  of  the  Phase  5  System  Translator. 
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3.5  Task  5  —  Implement,  Maintain,  and  Demonstrate  GMAP 

Task  6  included  four  Subtasks: 

5.1  Implement  GMAP 

5.2  Maintain  GMAP 

5.3  Project  Performance  and  Benefits  Analysis 

5.4  Demonstrate  GMAP. 

Subtask  5.1  demonstrated  the  effectiveness  of  the  GMAP  system  throu^  implementation 
in  contractor,  customer,  and  outside  supplier  computer  systems.  Subtask  5.2  provided  modifies* 
tions  to  the  GMAP  system  during  testing  as  required.  Subtask  5.3  identified  benefits  from 
implementing  GMAP  in  product  life  cycle  applications.  Under  Subtask  5.4,  several  videotapes 
were  produced  to  demonstrate  the  GMAP  system  performance. 

3.5.1  Implement  GMAP  (Subtask  5.1) 

The  GMAP  system  software  was  installed  at  MCAIR  facilities  to  test  the  components  as 
part  of  the  development  process.  For  example,  the  Schema  Manager  and  MAS  were  installed  on 
MC air’s  IBM  equipment  in  St.  Louis  for  testing  in  the  PDDI  program.  In  addition,  MCAIR 
installed  the  N/VI  and  the  System  Translator  on  its  equipment  during  the  GMAP  effort.  These 
activities  were  described  in  the  both  the  System  Test  Plan  and  the  System  Test  Report. 

Additional  implementations  of  GMAP  occurred  as  part  of  the  application  demonstrations. 
MCAIR  redemonstrated  applications  performed  under  the  PDDI  program  to  ensure  that  the 
system  component  software,  enhanced  for  GMAP,  stiU  performed  as  designed  with  parts  based 
on  PDDI  schema  and  of  less  complex  geometry  than  blades  and  disks.  The  schema  flexibility  of 
system  component  software  was  established. 

The  front  end  of  the  Display  Query  VAX  redemonstration,  conducted  at  MCAIR,  required 
an  IBM  4340  computer  environment.  The  Display  Query  software  leg  of  the  demonstration  was 
p>erformed  on  the  VAX  11/780  computer  system.  The  user  interacted  with  the  Display  Query 
Software  and  the  Database  Retrieval  Software  using  an  Evans  and  Sutherland  PS2  Graphics 
Terminal. 

The  Classification  and  Coding  redemonstration,  also  conducted  at  MCAIR,  required  an 
IBM  43xx  computer.  The  user  interfaced  with  the  software  and  the  model  through  a  PS  300 
Evans  &  Sutherland  graphics  terminaL 

3.5. 1.1  Pratt  &  Whitney  Implementations 

The  Parametric  Cooled  Tiubine  Blade  demonstration  took  place  on  an  IBM  5080 
workstation,  running  on  an  IBM  3090-200E  mainframe  computer  at  Pratt  &  Whitney  facilities 
in  East  Hartford,  Connecticut. 

The  PROCAP  application  was  developed  as  a  prototype  in  the  Manufacturing  Division  of 
Pratt  &  Whitney  with  programming  support  from  the  Engineering  Division.  The  testing  took 
place  in  the  East  Hartford,  Connecticut  plant  The  PROCAP  demonstration  was  performed  on 
an  IBM  5080  workstation  linked  to  an  IBM  3090  mainframe  computer.  The  workstation 
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consisted  of  a  5080  graphics  terminal  and  an  alphanumeric  screen  (IBM  3179  terminal)  and 
keyboard.  The  PROCAP  output  tables  were  displayed  on  the  alphanumeric  screen.  The  software 
is  written  in  FORTRAN. 

Another  Pratt  &  Whitney  implementation  included  the  internal  machining  application  for 
the  Casting  Tooling  demonstration.  An  IBM  working  form  GMAP  model  was  fed  to  an 
application  specific  translator  which  used  the  MAS  to  convert  it  to  an  ANVIL  part  file.  The 
ANVIL  part  file  was  then  used  for  N/C  programming.  The  target  N/C  system  was  ANVIL  4000, 
based  on  an  IBM  mainframe  platform.  Since  ANVIL  4000  did  not  stq>port  NURB  rq>re8entation 
of  free  form  curves  and  surfaces,  the  GMAP-supplied  geometry  was  reconstructed  by  ^e 
translator  through  the  use  of  a  parametnc  evaluator. 

All  the  tests  for  the  Feature-Based  N/C  and  CMM  Programming  application  were 
conducted  at  Pratt  &  Whitn^  facilities  in  North  Haven  as  well  as  in  East  Hartford  Connecticut. 
The  PDD  model  created  was  inspected  using  the  System  Translator  on  an  IBM  mamframe  under 
the  VM  operating  system.  The  postprocessing  of  the  APT  N/C  source  program  was  performed  on 
an  IBM  mainframe  under  the  VM  operating  system,  using  the  IBM  APT  N/C  product,  and  the 
Monarch  VMCRT  postprocessor.  The  postprocessed  machine  language  N/C  program  was 
executed  on  a  Monarch  vertical  machining  center  with  rotary  table. 

The  CMM  inspection  of  the  casting  tooling  electrode  was  also  performed  on  a  DEA  CMM 
machine  located  within  Pratt  &  Whitney’s  North  Haven,  (^oimecticut  manufacturina  facility. 
The  DMIS  CMM  source  program  was  postprocessed  on  a  Digital  Electronics  Corporation  (DEC) 
VAX  minicomputer  running  under  the  VMS  operating  system,  using  the  DEA  V1.0  prototype 
DMIS  translator.  The  postprocessed  machine  language  CMM  program  was  then  executed  on  ^e 
DEA  CMM  in  North  HavetL 

The  Disk  Design  ^plication  was  performed  at  Pratt  &  Whitney’s  engineering  fecilities  in 
West  Palm  Beach,  Florida  a  using  SUN -based  CADDS4X  workstation.  A  specific  translator  was 
written  to  translate  the  CADDS4X  part  model  into  the  GMAP  working  form. 

In  the  supplier  electrode  machining  application,  a  GMAP  exchange  format  model  of  the 
EDM  electrode  was  transmitted  to  Mold  Masters  of  Mentor,  Ohio,  a  Pratt  &  Whitney  casting 
tooling  supplier.  This  model  was  translated  into  Mold  Masters’  Computervision  CADDS4X 
system,  based  on  a  SUN/UNDC  platform. 

Another  supplier  implementation  was  the  Disk  Forging  application.  The  demonstration 
consisted  of  model  building  at  Pratt  &  Whitney,  translation  to  the  exchange  format  for  delivery 
to  Wyman  Gordon,  entry  of  the  SRON  data  at  Wyman  (jordon,  and  translation  to  the  exchange 
format  for  delivery  back  to  Pratt  &  Whitney. 

Postprocessing  of  the  DMIS  for  the  OMM  inspection  was  performed  on  an  OGP  Intelligent 
Qualifier  Machine  at  OGP’s  Rochester,  N.Y.  facility.  The  DMIS  inspection  program  was 
prepared  at  Pratt  &  Whitney  in  East  Hartford. 

The  Engine  Case  Boss  Inspection  application  was  jointly  coixlucted  by  Pratt  &  Whitney 
and  the  Department  of  Mechanical  Engineering  at  RPI,  in  TVoy,  New  York.  This  involved 
implementing  the  GMAP  software  on  the  RPI  IBM  system. 
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3.5.2.1  PDD  Editor 

Informal  testing  and  debugging  of  the  PDD  Editor  occurred  jointly  between  Pratt  & 
Whitney  and  m  during  PDD  model  building.  The  results  of  the  PDD  Editor  testing  showed  that 
all  entities  were  created,  modified,  and/or  maintained  as  per  the  GMAP  schema  qiecification. 

While  testing  the  individual  options,  it  was  found  that  all  but  three  functioned  as  designed. 
The  options  with  problems  were:  FILE  MERGE  and  RE^EN  data  thd  not  work  correctly,  and 
the  NETLIST  options  forced  the  user  to  halt  program  execution.  These  errors  were  corrected 
with  the  appropriate  programming  changes. 

3.5.2.2  Casting  Tooling  Demonstration 

The  results  of  comparing  the  original  source  data  Hie  to  the  ANVIL  part  indicated  that 
there  war  agreement  within  0.00001  inch  for  the  tip  sections.  However,  the  transition  area 
between  blade  and  root  showed  a  mismatch  of  0.004  inch.  To  locate  the  source  of  this  error,  the 
source  data  'Ue  was  read  into  CAEDS,  expanded,  and  profiles  were  created.  When  compared  to 
the  electrode,  the  same  mismatch  was  found  in  the  transition  area.  This  indicated  that  the 
electrode  model  '•as  not  expanded  correctly  in  CAEDS.  Since  this  would  not  affect  the  integrity 
of  the  GMAP  softvt  are  or  the  results  of  the  demonstration,  no  modifications  were  made  to  the 
model. 

3.5.2.3  Disk  Design  Demonstration 

In  verifying  exchange  format  accuracy,  it  was  found  that  the  exchange  format  definition  did 
not  address  a  default  number  of  significant  digits.  Since  the  IBM  mainframe  and  the  UNIX 
workstation  have  different  defaults,  this  created  differences  between  exchange  files  created  on 
the  two  different  systems.  This  was  corrected  by  providing  consistent  output  between  two 
systems.  This  problem  did  not  occur  when  exchanging  working  form  files. 

3.5.2.4  Process  Capabilities  Demonstration 

A  working  form-to-working  form  exchange  across  dissimilar  systems  was  attempted  in  the 
PROCAP  demonstration.  The  exchange  format  had  to  be  used  because  of  incompatibility.  The 
problem  was  discovered  during  a  parallelism  check  of  a  line  bound  on  one  end  by  an  end  point  of 
an  arc.  The  check  failed.  The  precision  of  real  numbers  on  the  SUN  were  incompatible  with  the 
IBM. 

3. 5.2.5  Disk  Forging  Demonstration 

Extensive  use  of  the  GMAP  note  entity  was  made  to  represent  the  various  information 
items  contained  on  the  SRON  paper  form.  No  specific  entities  exist  in  the  GMAP  schema  which 
can  capture  this  information  directly.  To  distinguish  between  the  classes  of  information  being 
represented  in  this  fashion,  an  ad-hoc  technique  was  adopted  that  consisted  of  embedding  a  text 
string  in  the  note  field  of  the  note  entity  to  represent  the  unique  function  of  each  note  item. 
Although  this  technique  worked,  it  required  communication  between  the  application  program¬ 
mers  involved  in  the  project. 
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3.5.2.6  Boss  N/C  Programming  Demonstration 

Si'.ice  the  CIMPLEX  database,  from  which  the  N/C  program  was  generated,  was  a  CSG 
system,  feature  evaluation  order  was  important.  For  example,  a  protrusion  firom  the  bottom  of  a 
pocket  would  be  obliterated  if  its  volume  were  added  before  removal  of  the  pocket’s  volume. 
GMaP  provided  the  needed  information  via  the  PRIM-FEAT— BOUND/620  entity,  but  more 
then  one  approach  was  possible.  As  a-rasult,  the  builders  of  the  GMAP*CIMPLEX  translator 
hr.d  to  verbally  communicate  with  the  model  builders  to  agree  on  a  particular  method  for  this 
demonstration. 

GMAP’s  methods  for  referencing  individual  faces  of  form  features  caused  difficulties  when 
defining  tolerance  targets  and  datums.  Both  situations  arose  with  the  top  face  of  the  boss’s 
flange.  The  geometry  of  the  face  was  defined  as  a  PLANE/363,  which  was  a 
PRlM_FEAT_BND/620  for  the  top  of  the  flange.  Since  GMAP  tolerance  entities  can  be  ^)plied 
to  shape  data  but  not  to  geometric  data,  the  plane  could  not  be  directly  toleranced  or  used  as  a 
datum.  Instead,  the  topology  of  the  flange’s  top  face  was  defined  to  provide  a  hook  for  the 
tolerance  data.  This  approach  required  definition  of  forty  otherwise  unneeded  entities.  An 
alternative  and  more  reasonable  approach  would  have  been  to  identify  the  plane  as  CON¬ 
STRUCTED— GEOMETRY/403,  which  could  be  toleraiM:ed.  This  approach  would  have  entailed, 
for  example,  indicating  that  the  plane  was  normal  to  an  appropriately  specified  vector  and 
contained  an  appropriate  point.  Intended  usaj^  of  constructed  geometry  needs  to  be  explicitly 
c  ;fined  to  ensure  that  modelers  will  use  that  approach  over  defining  topology  when  appropriate. 

The  bottom  point  required  for  a  BLIND— HOLE3/527  was  incorrectly  defined  in  the 
implemented  GMAP  schema  as  a  COORDINATE2/213.  As  specified  in  the  GMAP  system 
specification,  a  COORDINATE3/313  was  required.  The  implementation  of  the  schema  was 
corrected. 

A  deficiency  was  found  in  the  GMAP  schema’s  definition  of  the  SURF— OF— REV/365. 
Since  the  sweep  axis  was  specified  by  a  direction  only,  there  was  no  means  of  specifying  an  axis 
which  did  not  cross  the  origin.  The  missing  generality  was  provided  by  changing  the  schema 
definition  of  the  axis  from  a  VECTOR3/314  to  a  PT— VECTOR3/316. 

3.5.2.7  Display  Query  VAX  Working  Form  Redemonstration 

One  limitation  encountered  in  this  redemonstration  was  that  the  query  fimction  did  not 
allow  all  displayed  entities,  or  instances  of  entities,  to  be  queried.  Modifications  to  ensure  full 
model  interrogation  are  still  required  if  this  software  is  used  in  production.  Also,  interrogation  of 
data  levels  was  downward  only.  The  ability  to  obtain  “entity  users’’  directly  would  improve  its 
use  as  a  model  validation  tool. 

3.5.2.8  RFC  Interface  Demonstration 

During  RFC  Interface  testing,  the  UGIL_CONVERSION  would  randomly  ABEND  on  a 
WRITEV  command  with  a  field  width  specifier  too  big  for  target  string  or  negative.  In  the  call  to 
STR$TRIM  from  UGIL— CONVERSION,  the  third  argument  was  the  length  of  the  trimmed 
string.  The  argument  was  supposed  to  be  a  word  (2  bytes)  but  was  specified  as  a  4  byte  integer.  So 
garbage  bits  in  half  of  the  word  caused  incorrect  values.  This  number  was  used  in  a  WRITEV 
statement.  The  solution  was  to  use  a  2  byte  integer  as  specified  in  the  DEC  VAX  RTL  utilities 
manual  instead  of  the  4  b}rte  integer. 
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Also,  routine  PROCESS-APPROVAL  produced  a  UNIGRAPHICS  note  with  a  reference 
to  wrong  engineering  process  approval  specification.  This  was  caused  by  an  oversight  in  the 
design  of  the  schema  of  the  entities  that  prevented  a  consistent  reference  to  the  desired 
process— approval  entity.  To  solve  this  problem,  the  method  the  routine  uses  to  find  the  correct 
PROCESS— APPROVAL  entity  was  revised. 

In  a  third  incident,  the  generic  handler  routine  (GEN_HNDLR)  would  skip  certain 
entities.  The  logic  that  controls  the  flow  of  execution  was  in  error  and  caused  entities  that  were 
child  references  for  more  than  one  entity  to  be  ignored.  The  code  was  revised  to  process  all 
entities. 

3.5.2.9  IBIS  Interface  Demonstration 

During  IBIS  Interface  demonstration  software  development,  generation  of  a  shaded  image 
display  of  the  blade  showed  that  there  were  several  holes  in  some  of  the  surfaces  of  the  model. 
Some  tangent  values  for  the  surfaces  were  not  being  computed  correctly  due  to  an  error  in  the 
coded  version  of  the  algorithm  used  to  convert  from  the  parametric  surface  representation  to  the 
Coon’s  patch  surface  representation.  The  coded  version  of  the  algorithm  was  altered  to  allow  a 
greater  number  of  input  values  to  be  considered  in  creating  the  output  surface  representation. 

3.5.3  Project  Performance  and  Benefits  Analysis  (Subtask  5.3) 

The  GMAP  system  was  developed  to  provide  proof  of  concept  for  the  use  of  geometric  and 
nongeometric  data  in  engineering  and  in  downstream  explications  in  manufacturing,  inspection, 
and  product  and  logistics  support.  The  GMAP  software  demonstrated  that  it  could  function  as 
an  information  supplier  to  the  total  life  cycle  applications. 

The  successes  of  the  applications  demonstrated  across  the  product  life  cycle  offered  several 
benefits  from  implementing  GMAP  in  a  environment  similar  to  that  in  which  the  demonstra¬ 
tions  were  performed. 

3.5.?. 1  Parametric  Blade  Design  Application 

The  parametric  blade  design  demonstration  showed  that  it  is  possible  to  use  the  solid 
modeling  technique  to  configure  a  complex  geometry  (cooled  airfoil)  design  system  that  can 
provide  rapid  geometry  definition  and  analysis,  and  a  single,  complete,  and  accurate  PDD  model 
consistent  with  all  analysis  requirements. 

3.5.3.2  Supplier  Electrode  Machining 

Significant  reductions  in  labor  and  lead  time  were  demonstrated  by  the  direct  feed  and  use 
of  free-form  NURB  curves  and  surfaces  supplied  by  GMAP.  This  avoided  the  costly  and  time- 
consuming  reconstruction  of  geometry  by  the  supplier  associated  with  the  current  CAD  feed 
environment.  It  was  also  expected  to  result  in  more  accurate  transmission  and  use  of  geometry  as 
well  as  enable  the  use  of  nongeometric  PDD. 

3.5.3.3  Internal  Electrode  Machining 

This  application  demonstrated  that  GMAP  can  be  used  to  accurately  transmit  3-D 
aerodynamic  surface  geometry  between  dissimilar  CAD/CAM  systems.  The  original  N'lRB 
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^ometry  was  accurately  reconstructed  on  the  ANVIL  4000  system.  This  cc^ability  is  important 
to  existing  CAD/CAM  applications. 

3.5.3.4  Casting  Tooling  Applications 

The  CMM  and  OMM  inspections  verified  that  the  electrodes  produced  by  different 
suppliers  are  consistent.  This  is  an  important  result  because  variation  of  product  between 
suppliers  was  identified  during  the  Nee^  Analysis  phase  of  GMAP  as  a  key  problem  in  the 
current  manufacturing  of  turbine  blades.  '*  he  result  implies  that  GMAP  type  product 
descriptions  can  be  used  to  control  the  geometry  of  aerodynamic  surfaces  produced  by  different 
suppliers  using  different  CAD/CAM  systems. 

Successful  completion  of  the  four  Casting  Tooling  applications  demonstrated  that  GMAP 
could  support  complex  turbine  blade  manufacturing  and  inspection  applications.  In  addition,  it 
demonstrated  that  GMAP  could  provide  an  important  ingredient  in  the  solution  of  a  key 
technical  ^^roblem,  consistency  of  geometry  among  suppliers,  identified  during  the  manufacturing 
walkthroughs. 

3.5.3.5  OiBk  Design 

This  demonstration  showed  that  PDD  information  may  be  transferred  between  dissimilar 
computing  systems  in  two  ways,  exchange  format  and  working  form.  The  exchange  of  PDD 
information  using  the  exchange  format  is  best  used  for  external  communications.  The  exchange 
of  the  working  form  between  different  applications  was  much  faster  since  the  System  Translator 
was  bypassed.  However,  due  to  computer  hardware  differences,  the  working  form  to  working 
form  exchange  would  most  likely  be  used  only  for  applications  running  on  the  same  computer. 

3.5.3.6  Process  Capabilities 

The  PROCAP  demonstration  showed  the  application  of  the  GMAP  concepts  and 
components  to  the  feedback  of  manufacturing  information  to  design.  Today,  a  significant 
amount  of  emphasis  is  placed  on  quality  designs  based  on  manufacturing  capabilities  and 
meeting  customer  requirements.  PROCAP  prototyped  the  type  of  application  that  could  be  used 
to  feedback  information  from  any  stage  of  the  product  life  cycle. 

3.5.3.7  Feature-Based  N/C  and  CMM  Programming 

This  demonstration  showed  that  the  provision  of  intelligent,  data-rich  product  models  can 
enable  innovative  life  cycle  functional  applicationa  The  use  of  form  feature  approaches  to 
manufacturing  operations,  and  the  coupling  of  shape,  tolerance,  and  nonshape  information  to  the 
form  features,  could  offer  a  fiowerful  method  of  interfacing  to  product  data  information.  This 
type  of  application  can  be  expanded  to  deal  with  more  diverse  products,  form  features,  and  target 
machines  in  production  environments.  This  could  allow  the  concurrent  development  of 
machining  and  inspection  program  preparation  from  a  single  product  data  source. 

3.5.3.8  Disk  Forging 

This  application  provided  an  important  opportunity  to  demonstrate  the  extent  to  which  the 
GMAP  system  can  support  application-specific  data  requirements.  Such  extensiveness  is  an 
important  factor  in  the  practical  use  of  GMAP  concepts  in  the  CAD/CAM  environment. 
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The  ability  to  electronically  transmit  SRON  information  in  a  computer  file  was  a  more 
efficient  means  of  evaluating  nonconforming  material  for  reclamation  and  disposition.  The 
manufacturer  could  more  efficiently  evaluate  alternatives  for  final  part  machining. 

3.5.3.9  Case  Boss  Inspection 

The  case  boss  inspection  demonstration  showed  how,  through  the  use  of  complete  product 
definition  models,  organized  using  form  features  and  containing  tolerances,  inspection  program¬ 
ming  can  be  significantly  enhanced. 

3.5.3.10  Case  Boss  N/C  Programming 

The  demonstration  showed  that  GMAP  can  effectively  represent  and  communicate  PDD 
for  a  part  more  typical  of  industry  at  large  than  turbine  blades  and  disks. 

3.5.3.11  PDDI  Redemonstrations 

These  demonstrations  showed  the  ability  for  the  GMAP  system  to  support  product 
definitions  of  parts  other  than  GMAP  schema  based  blades  and  disks. 

The  redemonstration  of  product  models  and  demonstration  software  developed  under  the 
original  PDDI  project,  show  the  ability  to  retrieve  and  use  archived  models  with  enhanced 
GMAP  software  (MAS,  System  Translator,  working  form,  and  exchange  format).  Since  the 
GMAP  software  system  was  schema  independent,  there  is  potential  for  future  use  of  the  system 
with  other  schema  based  projects  and/or  production  systems. 

3.5.3.12  GMAP-to-RFC  interface 

The  RFC  interface  software  reduced  the  amount  of  time  and  effort  required  to  produce  an 
inspection  scan  plan.  In  the  future,  it  could  become  a  key  link  in  a  fully  automated  inspection 
system  or  provide  input  for  an  automatic  scan  plan  generator.  This  is  possible  because  the  RFC 
Interface  translated  a  computer  compatible  3-D  part  definition  to  the  RFC  system  (Unigraphics 
database). 

3.5.3.13  GMAP-to-IBIS  Interface 

The  GMAP-to-IBIS  Interface  translated  a  computer  compatible  3-D  part  definition  to  the 
IBIS  system  and  reduced  the  amount  of  time  and  effort  required  to  produce  an  inspection  plan. 
In  the  future,  it  too  could  become  a  key  link  in  a  fully  automated  inspection  system  or  provide 
input  for  an  automatic  inspection  plan  generator. 

Additionally,  IBIS  feedback  of  analyzed  flaw  trends  to  engineering  and  manufacturing 
could  lead  to  design  and  manufacturing  improvements  that  would  reduce  flaw  occurrence. 

These  benefits  provided  incentive  for  future  effort  to  store  the  IBIS  flaw  data  into  an 
accessible  database.  Tasks  required  include  organization  of  the  flaw  data  into  a  coherent 
structure  that  would  be  compatible  with  the  database,  development  of  software  that  would 
extract  the  flaw  data  from  the  flaw  history  files  and  store  it  in  the  database,  and  creation  of 
database  retrieval  software  tailored  for  flaw  history  analysis. 
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3.5.4  Demonstrate  GMAP  (Subtask  5.4) 

The  demonstrations  of  GMAP  technology  at  the  end  of  the  program  were  documented  by 
the  five  following  videotapes: 

1.  Executive  Overview 

2.  Technical  Summary 

3.  Blade  Life  Cycle 

4.  Disk  Life  Cycle 

5.  Plumbing  Attachment  Boss  Demonstrations. 

The  Executive  Overview,  presented  in  an  interview  format,  offered  the  views  of  various 
industry  experts  on  the  significance  of  GMAP  technology.  The  Technical  Summary  videoU^ 
described  the  technical  aspects  of  GMAP  from  an  overall  perspective.  Videotapes  3,4  and  5 
discussed  the  product  life  cycle  applications  that  were  selected  to  demonstrate  the  functionality 
of  GMAP  technology. 

The  fo.’owing  locations  were  visited  by  the  filming  crew  to  document  the  demonstrations; 

•  Pratt  Whitney,  Government  Engine  Biisiness  (GEB),  West  Palm  Beach, 

Florida 

•  OGP,  Rochester,  New  York 

•  ATP,  Campbell,  California 
.  SA-ALC 

•  Mold  Masters,  Mentor,  Ohio 

•  MCAIR,  St.  Louis,  Missouri 

•  IngersoU  Milling  Machine  Company,  Rockford,  Illinois 

•  Pratt  &  Whitney,  North  Haven  and  East  Hartford,  Connecticut. 

Draft  versions  of  the  “Technical  Summary,”  “Blade  Demonstration,”  “Disk  Demonstra¬ 
tion,”  and  “Case  Boss  Demonstration,”  videotapes  were  reviewed  by  the  IRB  and  the  Air  Force. 
The  IRB  members’  concerns  and  their  suggested  modifications  were  incorporated  by  the  Pratt  & 
Whitney  media  groups. 

Interviews  with  IRB  members  were  videotaped  at  the  sixth  IRB  for  the  “Executive 
Overview.”  Additional  interviews  with  Mr.  Gerry  Shumaker,  and  Mr.  Walter  Reimann,  the  then 
current  Air  Force  Chief  of  the  CIM  branch,  were  videotaped  at  Pratt  &  Whitney  for  use  in  this 
videotape.  This  videotape  was  delivered  shortly  after  the  end  of  the  contract  period. 

3.6  Task  6  —  Deliverable  Reports 

Task  6  was  included  as  part  of  GMAP  to  account  for  documentation.  A  variety  of  technical 
and  financial  reports  were  produced  in  accordance  with  the  Contract  Data  Requirements  List 
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(DD  Form  1423)  and  the  Integrated  Computer  Aided  Manufacturing  Life  Cycle  Documentation 
Schedule.  The  majority  of  these  documents  were  discussed  in  relation  to  the  technical  efforts 
that  they  support.  Section  4  of  this  document  provides  abstracts  of  many  of  these  documents.  A 
brief  synopsis  of  these  documents  is  presented  below. 

3.6.1  Research  and  Development  Status  Report 

This  report,  published  monthly,  was  designed  to  keep  project  management  informed  of 
activity  and  progress  toward  the  accomplishment  of  the  GMAP  objectives.  The  R&D  Status 
Report  was  a  brief  narrative  providing  monthly  status.  It  was  not  published  every  third  month. 
The  third  month’s  activity  was  covered  in  Interim  Technical  Reports. 

3.6.2  Interim  Technical  Reports  (ITRs) 

Interim  Technical  Reports  were  submitted  to  the  AFWAL/MLTC  for  review  at  the  end  of 
each  quarter.  They  provided  documentation  of  technical  information  gathered  during  each 
quarterly  contract  period.  ITRs  were  formatted  based  on  Ck>ntract  Work  Breakdown  Structure 
elements. 


3.6.3  ICAM  Life  Cycle  Documentation 


The  ICAM  Documentation  Standards,  1DS150120000C,  identify  several  technical  docu¬ 
ments  that  provide  detailed  information  on  specific  aspects  of  the  GMAP  program.  These  Life 
Cycle  documents  are  geared  to  the  development  Phases  of  the  program.  Section  4  of  this 
document  lists  those  documents. 


3.6.4  Final  Technical  Report 

The  Final  Technical  Report  summarizes  the  technical  achievements  of  the  program  by 
Work  Breakdown  Structure  element. 
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SECTION  4 

REFERENCE  MATERIAL 


4.1  UFE  CYCLE  DOCUMENTS 

Althoxigh  there  have  not  been  any  ICAM  Life  Cycle  documents  published  as  volumes  of  this 
Final  Technical  Report,  numerous  Life  Cycle  documents  produced  during  GMAP  provide 
s  jppcrtive  and  more  detailed  information  and  may  be  of  interest.  They  are  summarized  briefly 
below.  A  sample  Document  Request  Order  Form  is  shown  in  Figure  4-1. 

Scoping  Document  (SD)  —  The  Scoping  Document  was  the  foundation 
document  for  the  entire  project  effort.  It  documented  the  mutual  understanding 
of  the  contractor  and  of  the  Air  Force  about  the  intent  of  the  project.  The  SD 
also  served  as  a  basis  for  determining  satisfactory  contract  completion. 
Objectives  of  the  contract  were  established  by  the  SD.  These  objectives  were 
related  to  the  contract  work  statement  by  defining  the  bounds  of  the  required 
tasks.  (SD560240001U) 

Needs  Analysis  Document  (NAD)  —  The  NAD  provided  a  record  of  the  needs  of 
the  to-be  system.  It  was  used  as  an  analysis  tool  to  determine  system 
requirements,  and  it  was  a  basis  for  preliminary  state-of-the-art  technology 
investigation.  (NAD560240001U) 

The  to-be  system  needs  included  improvements  to  functions  that  were  paitiaUy 
performed,  incorrectly  performed,  or  that  should  have  been  performed.  A  benefit 
rationale  in  terms  of  cost,  performance,  and  human  factors  as  applicable, 
accompanied  each  need.  Needs  were  prioritized  according  to  benefits  to  be 
derived. 

State-of-the-Art  Review  Document  (SAD)  —  The  SAD  was  used  to  determine 
the  feasibility  of  solving  requirements  as  they  related  to  relative  cost,  schedule, 
and  performance.  This  document  was  used  to  provide  possible  solution 
approaches  even  though  actual  system  solutions  were  not  yet  designed. 
(SAD560240001U) 

System  Requirement  Documentation  (SRD)  —  This  document  presented  a 
system  requirement  traceable  to  the  needs  identified  in  the  NAD.  The  SRD  was 
also  used  as  an  initial  basis  for  generalizing  project  costs.  (SRD560240001U) 

System  Specification  (SS)  —  This  document  detailed  the  requirements  of  the 
SRD  in  terms  of  function,  performance,  physical  and  interface  requirements  and 
specific  design  constraints.  (SS560240001U) 

System  Design  Specification  (SDS)  —  The  SDS  was  the  transition  document 
from  overall  system  requirements  to  overall  system  design.  It  formed  the 
foundation  for  the  remainder  of  the  development  process.  (SDS560240001U) 


4-1 


Cl  FTR560240001U 
September  1989 

Development  Specification  (DS)  —  This  document  decomposed  q>ecific  man¬ 
ageable  entities  called  configuration  items  (CIs)  to  a  level  that  enabled  detailed 
design.  It  described  the  functions,  performance,  environment,  interfaces,  and 
design  requirements  for  each  Cl.  There  was  a  DS  for  the  IBIS  interface  and  a  DS 
for  the  RFC  interface  in  the  GMAP  project.  (IBIS  DS560240021U;  RFC 
DS560240011U) 

Product  Specification  (PS)  —  A  PS  was  produced  for  each  Development 
Specification:  a  version  for  the  as-designed  PS  and  a  version  for  the  as-built  PS. 

The  PS  included  descriptions  of  the  structure,  functions,  language,  database 
requirements,  interfaces,  and  quality  assurance  provisions.  The  as-built  PS 
included  all  of  the  changes  made  to  the  as-designed  PS  throughout  the 
remainder  of  the  project  life  cycles.  (IBIS  PS560240021U;  RFC  PS560240011U) 

System  Test  Plan  (STP)  —  The  STP  described  concepts,  criteria  or  standards, 
tools,  and  strategies  for  testing  the  overall  system.  Written  at  the  system  level,  it 
addressed  each  requirement  identified  in  the  SS.  (STP560240()01U) 

System  Test  Report  (STR)  —  This  document  described  the  tests  conducted  and 
the  methods  used  in  analyzing  test  results.  The  STR  also  presented  system 
capabilities  and  deficiencies  for  review.  The  status  of  the  system  in  light  of  the 
test  results  was  evaluated.  (STR560240001U) 

Unit  Test  Plan  (UTP)  —  A  Unit  Test  Plan  was  written  for  both  IBIS  and  RFC 
and  was  traceable  to  each  requirement  as  stated  in  the  DS.  It  assured  that  the 
performance  objectives  stated  in  the  OS  were  adequately  validated.  (IBIS 
UTP560240021U;  RFC  UTP560240011U) 

Unit  Test  Report  (UTR)  —  The  UTR  described  the  tests  conducted  on  IBIS  and 
RFC,  the  results,  the  method  used  in  analyzing  test  resiilts,  the  capabilities  and 
deficiencies  for  review,  and  evaluated  the  status  of  the  Interface  in  light  of  the 
test  results.  (IBIS  UTR560240021U;  RFC  UTR560240011U) 

Applications  Manuals  —  Applications  manuals  included  appropriate  user  and 
operator  manuals.  User  Manuals  (UM)  were  the  primary  reference  for  users,  who 
may  have  had  a  wide  range  of  technical  sophistication  and  experience.  Operator 
Manuals  (OM)  described  the  operating  system  conunands  and  characteristics  so 
that  computer  operators  and  programming  personnel  could  operate  the  software. 

In  some  cases,  these  manuals  were  combined  (U/OM).  They  were  written  in  a 
step-by-step  fashion  to  clarify  and  emphasize  the  procedures  associated  with  the 
computer  programs.  Those  manuals  produced  include: 

•  Schema  Manager  User’s  Manual  (UM560240011U) 

•  System  Translator  User’s  Manual  (UM560240021U) 

•  Model  Access  Software  with  Name/Value  Interface 
(UM560240031U) 
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•  System  Components  Operator’s  Manual  (OM560240001U) 

•  GMAP-to-RFC  Interface  User/Operator  Manual 
(U/OM560240011U) 

•  GMAP-to-IBIS  Interface  User/Operator  Manual 
(U/OM560240021U) 

•  PDD  Editor  User/Operator  Manual  (U/OM560240031U) 

GMAP  Technical  Transfer  Documents  (TTD)  —  There  were  three  TTDs.  The 
Demonstration  Model  Description  document  described  the  PDD  of  the  GMAP 
demonstration  models.  It  documented  the  entities  and  attributes  that  comprised 
the  demonstration  models  and  gave  a  brief  description  of  each  demonstration. 

T  he  document  was  a  guide  to  build  the  models  in  geometric  modelers  and  the 
Pi.D  Editor.  (TTD560240001U)  The  Product  Information  Exchange  System 
(PIE."!  document  described  the  operation  of  the  user  interface  to  the  GMAP 
software  called  PIES.  PIES  helps  a  user  access/store/query/verify  data  from  a 
PDES  fort.:  at  file.  (TTDS60240002U)  The  Functional  Requirements  of  Product 
Modeler  document  (TTD560240002U)  built  upon  the  work  described  in  the 
Minimum  Requirements  of  a  Product  Modeler  work  appended  to  the  SRD. 

Specification  Change  Notice  (SCN)  —  The  SCN  was  used  to  add  an  addendum 
to  the  System  Components  Operators  Manual  describing  installation  of  the  PDD 
Editor  on  additional  platforms.  (SCN-1) 

Manufacturing  Methods  Report  (MMR)  —  This  PDDI  document  provided 
preliminary  benefits  analyses  (MMR560240001U)  of  the  GMAP  project  and  a 
plan  for  tracking  benefits.  (MMR560240002U) 

Final  Technical  Report  (FTR)  —  This  document  provided  a  comprehensive 
review  of  the  GMAP  project  and  its  accomplishments.  (FTR56020001U) 
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SUBMIT  DOCUMERT  REQUESTS  TO:  AFWAL/MLTC 

ICAM  Program  Library 
Wright-Patteraon  AFB,  OR  45433 


DOCUMENT  CONFIGURATION 
ITEM  NUMBER 


TTFLE  OF  DOCUMENT 


INDICATE  (  ) 

DOCUMENT 
REQUESTED 


PLEASE  PRINT 


NAME:  . 
TITLE: 


HAIL  CODE: 


DEPARTMENT: 
COMPANY:  _ 


STREET  OR  P.O.  BOX: 
CITY:  _ 


STATE: 


ZIP; 


REQLlIREMENt  FOR  DOCUMENT 

Oocunent(t)  requested  for  the  purpose  of  (Intended  use  end  progrui/project  application 
must  be  provided): 


Documents  generated  under  the  contract  contain  controlled  distribution  and  export  control 
clauses. 

I  am  a  U.S.  citizen,  I  am  employed  by  a  U.S.  organization/company  and  am  aware  that  the 
use  of  these  Air  Force  dociatents  must  comply  with: 

U.S.  EXPORT  CONTROL  UWS 

This  docuaient  contains  information  for  eianufacturing  or  using  munitions  of  war.  Export 
of  the  information  contained  herein,  or  release  to  foreign  nationals  within  the  United 
States,  without  first  obtaining  an  export  license,  it  a  violation  of  the  International 
Traffic  in  Arms  Regulations.  Such  violation  is  subject  to  a  penalty  of  up  to  2  years 
imprisonment  and  a  fine  of  $100,000  under  22  USC  2778. 


Signature: 


Telephone  No.: 


Date: 


Figure  4-1.  Document  Request  Order  Form 
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4.2  INTERIM  TECHNICAL  REPORTS 

Erxh  Interim  Technical  Report  (ITR)  encompassed  the  work  associated  with  a  q>ecified 
reporting  period.  They  provided  a  brief  summary  of  the  overall  project  including  pertinent 
observations;  nature  of  technical  problems;  positive,  as  well  as  negative,  results;  and  (tesign 
criteria  established  through  the  reporting  period. 

The  body  of  each  ITR  consisted  of  the  sections  described  below. 

•  Section  1:  Introduction  —  This  section  described  the  project  as  a  whole  and 
its  objectives.  It  listed  the  tasks  and  subtasks  that  comprised  the  project.  It 
was  generic  in  nature  and  did  not  change  from  one  ITR  to  another. 

•  Section  2:  Executive  Summary  —  This  section  consisted  of  three  subpara¬ 
graphs  as  follows: 

2.1  Synopsis  of  the  work  done  prior  to  the  current  reporting 
period  which  has  been  covered  in  previous  ITRs. 

2..'*  Outline  of  the  material  contained  in  the  ITR. 

2.3  Outline  of  the  goals  expected  to  be  accomplished  during  the 
next  reporting  period. 

•  Section  3:  Project  Accomplishments  for  the  Reporting  Period  —  This 
section  was  organized  in  serial  order  by  Work  Breakdown  Structure  task  and 
subtask  that  were  worked  on  during  the  reporting  period.  Those  tasks  and 
subtasks  not  officially  worked  on  were  not  listed. 

•  Section  4:  Reference  Documents  —  This  section  contained  two  items: 

4.1  List  of  Previous  Interim  Reports  Showing  Document 
Number  and  Providing  Order  Blanks. 

•*.  '  ril'^tractr  of  Approved  ..  uc  Cycle  Documents  Produced  to 
Date  with  Ordering  Information  and  Order  Blanks. 

Following  is  a  list  of  Interim  Technical  Reports  produced  during  GMAP. 

1.  Interim  Technical  Report  No.  1  (ITR560240001U) 

“Geometric  Modeling  Applications  Interface  Program"  February  1986 
(Period  1  August  1985  •  31  October  1985). 

2.  Interim  Technical  Report  No.  2  (n'R560240002U) 

“Geometric  Modeling  Applications  Interface  Program"  May  1986 
(Period  1  November  19^  •  31  January  1986). 

3.  Interim  Technical  Report  No.  3  (ITR560240003U) 

“Geometric  Modeling  Applications  Interface  Program"  August  1986 
(Period  1  February  1986  -  30  April  1986). 
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4.  Interim  Technical  Report  No.  4  (rrR560240004U) 

“Geometric  Modeling  Applications  Interface  Program”  November  1986 
(Period  1  May  1986  •  31  July  1986). 


5.  Interim  Technical  Report  No.  5  (ITR560240(X)5U) 

“Geometric  Modeling  Applications  Interface  Program”  January  1987 
(Period  1  August  1986  •  31  October  1986). 

6.  Interim  Technical  Report  No.  6  (n'R5602400()6U) 

“Geometric  Modeling  Applications  Interface  Program”  April  1987 
(Period  1  November  1986  •  31  January  1987). 


7.  Interim  Technical  Report  No.  7  (rrR560240007U) 

“Geometric  Modeling  Applications  Interface  Program”  August  1987 
(Period  1  February  1987  -  30  April  1987). 

8.  Interim  Technical  Report  No.  8  (ITR560240(X)8U) 

‘  Geometric  Modeling  Applications  Interface  Program”  December  1987 
(Period  1  May  1987  -  31  July  1987). 


9. 


Interim  Technical  Report  No.  9  (ITR560240009U) 

“Geometric  Modeling  Applications  Interface  Program”  March  1988 
(Period  1  August  1987  •  31  October  1987). 


10.  Interim  Technical  Report  No.  10  (ITR560240010U) 

“Geometric  Modeling  Applications  Interface  Program”  July  1988 
(Period  1  November  1987  -  31  January  1988). 


11.  Interim  Technical  Report  No.  11  (ITR560240011U) 

“Geometric  Modeling  Applications  Interface  Program”  July  1988 
(Period  1  February  1988  -  30  April  1988). 


12.  Interim  Technical  Report  No.  12  (ITR660240012U) 

“Geometric  Modeling  Applications  Interface  Program”  October  1988 
(Period  1  May  1988  -  31  July  1988). 

13.  Interim  Technical  Report  No.  13  (ITR560240013U) 

“Geometric  Modeling  Applications  Interface  Program”  January  1989 
(Period  1  August  1988  -  31  October  1988). 

14.  Interim  Technical  Report  No.  14  (ITR560240014U) 

“Geometric  Modeling  Applications  Interface  Program”  June  1989 
(Period  1  November  1988  •  31  January  1989). 
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4.3  VIDEO  TAPES 

The  demonstrations  of  GMAP  technology  at  the  end  of  the  program  resulted  in  the  five 
following  videotapes: 

1.  Executive  Overview, 

2.  Technical  Summary, 

3.  Blade  Life  Cycle, 

4.  Disk  Life  Cycle, 

5.  Plumbing  Attachment  Boss  Demonstrations. 

The  Executive  Overview,  presented  in  an  interview  format,  offered  the  views  of  various 
industry  experts  on  the  significance  of  GMAP  technology.  The  Technical  Summary  videotape 
described  the  technical  aspects  of  GMAP  from  an  overall  perspective.  Videotapes  3,  4  and  5 
discussed  the  product  life  cycle  applications  that  were  selected  to  demonstrate  the  functionality 
of  GMAP  technology. 

4.4  TECHNICAL  PAPERS 

Below  is  a  list  of  technical  papers  produced  by  GMAP  personnel  during  the  program. 

Identification  of  Product  Definition  Data  in  a  Manufacturing  Enterprise  —  A 
Case  Study.  R.  Lessard,  United  Technologies  Research  Center  and  R.  Disa, 

Pratt  &  Whitney,  March  1986. 

Use  of  Product  Models  in  a  CIM  Enidronment,  D.  Koziol  Emmerson  and  K. 
Perlotto,  Pratt  &  Whitney,  March  1987. 

Technical  Issues  in  Product  Data  Transfer,  Richard  Lopatka,  Pratt  &  Whitney, 
September  1987. 

implementation  of  GMAP  Technologies  for  Logistic  Support  Applications, 

Donald  L.  Deptowicz,  Pratt  &  Whitney,  January  1988. 

Barriers  to  PDES  Approval,  Anthony  Day,  Sikorsky,  and  Richard  Lopatka, 

Pratt  &  Whitney,  April  1988. 

PDD:  Implementation  issues,  Diane  Emmerson  and  Priscilla  Blasko,  United 
Technologies  Corporation,  Proceedings  of  AUTOFACT  '88,  October  1988. 

Geometric  Modeling  Applications  Interface  Program:  A  Prototype  for  Active 
File  Exchange,  Linda  Phillips  and  Diane  Emmerson,  United  Technologies 
Corporation,  Proceedings  of  National  Computer  Graphics  Association,  April 
1989. 

4.5  COMPUTER  PROGRAMS 

Section  3.4.1  describes  the  software  that  was  produced  under  GMAP  and  includes 
Table  3-23  which  identifies  the  software  versions  and  platforms  for  GMAP  software  use. 
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4.6  SOFTWARE  DOCUMENTATION 
See  “Manuals”  under  Section  4.1. 

4.7  DISPLAYS 

A  display  was  produced  for  the  Industrial  Modernization  Incentives  Program  (IMIP)  in 
December  1988.  The  display  wiU  also  be  used  at  the  end-of-contract  Govemment/Industry 
debriefing. 

4.8  TERMS  AND  ACRONYMS 

A  glossary  of  terms  frequently  used  in  GMAP  which  may  be  included  in  this  Final 
Technical  Report  is  provided  below.  A  list  of  acronyms  and  abbreviations  used  in  GMAP  is  also 
included  in  this  section. 

4.8.1  Terms  Used  in  GMAP 

Accept/Reject/Incomplete  Notice  —  A  display  on  the  cell  computer  that  indicates  the  final 
status  of  the  engine  disk. 

Accept  Acceptable  within  tolerance  specified  by  engine  manufacturer 

Reject  -  Rejected  because  of  flaw(s)  outside  the  range  of  acceptable 
tolerances 

Incomplete  -  Part  cannot  be  inspected 

Access  Software  —  A  set  of  routines  for  creating,  managing  and  querying  an  in-core  Working 
Form  model. 

Angular  —  An  angular  size  tolerance  is  used  to  tolerance  the  size  of  an  angular  feature 
independent  of  its  angular  location  along  an  arc. 

Application  —  A  method  of  producing  a  specific  result. 

Application  Request  —  A  request  initiated  by  an  application  program,  either  through  batch  or 
interactive  processing,  which  will  interrogate  the  model  through  the  PDDI  Access  Software  to 
obtain  or  operate  on  specific  information  regarding  the  model  and  its  components  or  elements. 

Application  Requested  Data  —  The  data  which  fulfills  the  application’s  original  request  and 
which  is  in  the  proper  format  and  readable  by  the  application. 

Architecture  —  A  design  or  orderly  arrangement. 

ASCII  —  American  Standard  Code  for  Information  Interchange. 

As-ls  —  The  present  condition. 

Attribute  —  A  quality  of  characteristics  element  of  any  entity  having  a  name  and  a  value. 
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B-Spline  —  A  spline  defined  by  a  control  polygon,  B-spline  basis  functions,  and  an  associated 
knot  vector.  A  Bezier  curve  is  a  special  case  of  a  B-spline;  a  nurb  is  the  most  general  case  of  a 
B-spline. 

Bezier  Curve  —  A  type  of  curve  defined  by  a  set  of  vertices  called  a  control  polygon  and  a  set  of 
basis  functions.  The  basis  fimctions  are  known  as  Bernstein  polynomials.  K  vertices  define  a 
curve  of  order  K-1. 

Binding  —  Establishing  specific  physical  references  to  data  structures  for  an  application 
program;  may  be  performed  at  compile  time  or  at  run  time. 

Blend  —  A  smooth,  continuous  transition  from  one  surface  to  another. 

Boundary  Representation  —  A  topology  imposed  on  3-D  geometric  entities  to  yield  a  general 
solid  mod^l.  That  model  describes  an  object  by  describing  its  boundary  area. 

Body  of  Rb  *0101100  (BOR)  Representation  —  A  topology  in  which  an  object  is  represented  as  the 
volume  swept  by  a  curve  rotated  about  a  line.  This  is  a  boundary  representation  in  which  the 
curve  represeni.  the  surface  area  of  the  object. 

Bounded  Geometry  —  Geometry  that  has  limits  defined  by  its  mathematical  domain  or  range. 

Calibration  Biock  Parameters  (Scale  Factors)  —  Nondestructive  test  parameters  used  to  adjust 
a  specific  cell.  These  parameters  are  obtained  from  the  calibration  blocks  located  at  each  ceil. 

Circumferential  —  A  circumferential  tolerance  specifies  the  tolerance  zone  within  which  the 
average  diameter  of  a  circular  feature  must  He.  The  average  diameter  is  the  actual  circumference 
divided  by  pi  (3.14159).  A  circumferential  tolerance  is  a  specific  example  of  a  peripheral  or 
perimeter  tolerance  for  a  general  curve. 

Class  —  A  collection  of  entities  that  are  alike  in  some  manner. 

CLIST  —  IBM  Command  lists. 

Composite  Curve  —  A  group  of  curve  segments  that  are  continuous. 

Compound  Feature  Representation  —  An  enumerative  feature  representation  in  which  at  least 
one  component  is  itself  a  feature.  For  example,  a  bolt  hole  circle  might  be  represented  as  a  list  of 
individual  hole  features. 

Concentricity  (Generic)  —  A  concentricity  tolerance  specifies  a  cylindrical  tolerance  zone  within 
which  the  axis  of  a  feature  must  He,  where  the  axis  of  the  zone  coincides  with  the  axis  of  the 
datum. 

Conceptual  Schema  —  Formally  speciHed  global  view  that  is  processing  independent,  covering 
information  requirements  and  formulation  of  independent  information  structures.  A  neutral 
view  of  data,  usually  represented  in  terms  of  entities  and  relations. 
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Conic  —  A  quadratic  curve  represented  ir  the  most  general  case  by  the  equation: 

Ax^  +  Bxy  +  Cyj  +  Dx  +  Ey  +  F  =  0. 

oonic  may  be  a  circle,  line,  ellipse,  parabola,  or  a  hyperbola  depending  on  the 
c  .flcients.  A,  B,  C,  D,  E,  and  F. 

Constraints  (Generic)  —  An  assertion  to  explicitly  specify  data  meaning  or  semantics.^ 

Context-Free  Grammar  —  The  syntax  of  the  language  gives  a  precise  specification  of  the  data 
without  interpretation  of  it. 

Constituent  —  A  specific  instance  of  an  entity  that  is  used  in  the  definition  of  some  other  entity. 

Data  Dictionary  —  A  catalog  of  all  data  elements  in  a  design,  giving  their  name,  definition, 
format,  source,  and  usage.  May  also  indude  data  types  c.d  value  limits. 

Defining  Airfoil  Sections  —  A  planar  or  conical  section  that  depicts  an  airfoil  profile.  Defining 
airfoil  sections  are  those  that  meet  aerodynamic  requirements.  Other  intermediate  sections  are 
added  for  Manufacturing  purposes. 

Dimension  —  A  par*  dimension  is  a  quantifiable  value  expressirj  f-'ze,  form,  or  location. 
Domain  —  The  set  of  values  permissible  in  a  given  context. 

Dynamic  Aliocation  —  The  allocation  (and  de-allocation)  of  memory  resources  as  required  by  the 
application.  The  opposite  is  static  allocation  where  a  fixed  size  segment  of  memory  is  available  to 
the  application. 

Eddy  Current  Cell  —  Hardware  used  to  perform  an  Eddy  current  inspection  operation  (surface 
flaws). 

Eddy  Current  Inspection  —  An  inspection  method  used  to  detect  internal  potential  flaws  on  a 
disk.  It  is  based  on  the  principle  of  sending  electromagnetic  signals  to  a  target  area  on  a  part  and 
detecting/interpreting  reflection  (Eddy  current)  from  the  target. 

Eddy  Current  Scan  Plan  —  An  interpreter  code  program  controlling  the  Eddy  current  inspection 
of  a  particular  geometry. 

Eddy  Current/Ultrasonic  Flaw  Data  Printout  —  A  printout  containing  size  and  location 
information  about  specific  flaw(s)  (both  critirol  and  noncritical)  associated  with  a  particular 
part. 

Entity  —  A  de'^cription  of  a  person,  place,  or  thing,  about  which  information  is  kept. 

External  Reference  —  A  reference  U>  some  quantity  of  data  that  exists  somewhere  outside  the 
scope  of  the  immediate  body  of  information. 

*  T.  J.  Teorey  and  J.  P.  Fry,  Design  of  Database  Structures,  1st  edition,  Prentice-Hali,  Inc., 
Englewood  Cliffs,  N.J.,  p.  463. 
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Feature  —  A  part  feature  in  the  dimensioning  and  tolerancing  context  is  a  feature  in  the  .^ense  of 
ANSI  Y14.5M,  that  is,  a  physical  component  portion  of  a  part,  such  as  a  surface,  hole,  slot,  and 
so  on,  that  is  used  in  a  tolerancing  situation.  Ir  the  dimensioning  and  tolerancing  context,  a 
fe  ture  consists  of  individual  or  groups  of  basic  shape  elements  used  to  defuie  the  physical  shs^ 
of  an  item.  Th's  general  dimensioning  and  tolerancing  use  of  features  is  to  be  distinguished  from 
Features.  The  word  “features”  alone  implies  dimensioning  and  tolerancing  features.  The  term 
“form  feature"  is  described  below. 

Feature  Pattern  —  A  geometric  pattern  of  occurrences  of  similar  form  features,  for  example,  a 
circular  pattern  of  scallops,  a  rectangular  array  of  holes. 

Feature  Representation  (Generic)  —  A  description  of  a  form  feature  within  the  context  of  a 
geometric  model. 

Feature  Type  —  A  name  applied  to  a  form  feature  that  is  suggestive  of  its  shape  and  size,  for 
example,  bole,  slot,  web. 

Feature  of  Su  (Generic)  —  A  feature  of  size  provides  a  geometric  location  capable  of  being 
referenced  for  us,,  with  datums  and  tolerances.  A  feature  of  size  can  be  a  GMAP  feature,  or  other 
referenceable  shape  elements  of  a  part  model  that  are  symmetric  about  a  point,  line,  plane,  axis, 
curve,  and  so  on.  When  a  feature  of  size  is  used  in  a  relationship  with  a  tolerance  or  datum,  its 
laature  of  symmetry  is  the  implied  reference. 

Flat  Pattern  Representation  (Extrusion  Representation)  —  A  topology  in  which  an  object  is 
represented  as  the  volume  swept  by  a  planar  polygon  moving  in  a  direction  normal  to  its  plane. 
The  polygon  may  have  internal  polygon  represent  the  surface  area  of  the  object. 

Flaw  Characteristics  —  Location,  length,  width,  depth,  and  nondestructive  test  parameters 
associated  with  a  specific  flaw. 

Flaw  Data  Packet  —  Packet  containing  nonevaluated  flaw  data.  Note  that  the  packet  can 
contain  zero  flaws. 

Flaw  Orientation  —  The  direction  of  the  major  characteristic  of  the  flaw  with  respect  of  the  part 
coordinate  system.  (See  the  notes  section  at  the  end  of  this  glossary.) 

Flaw  Suspect  Location  —  The  coordinate  location  of  a  possible  flaw  detected  during  a  survey 
mode  inspection  (six-axis  position  of  ultrasonic  cell,  seven-axis  position  of  Eddy  current  cell). 

Form  Feature  —  A  portion  of  a  part’s  geometry  that  is  useful  to  regard  as  an  entity.  In  a 
boundary  representation  context,  this  is  a  subset  of  the  part’s  surface  area. 

Form  Tolerance  —  Form  tolerances  are  used  to  control  the  form  of  model  features.  A  form 
tolerance  specifies  the  amount  that  an  actual  features  form  may  vary  from  nominal.  Form 
tolerance  include  straightness  tolerance,  flatness  tolerance,  roundness/circularity  tolerance, 
cylindricity  tolerance,  perpendicularity  tolerance,  parallelism  'olerance,  r^.gularity  tolerance, 
profile-of-a-line  tolerance,  profile-of-a-surface  tolerance,  circular-runout  tolerance,  true-direc- 
tion  tolerance,  and  mismatch  tolerance. 
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Functionality  —  (1)  To  show  that  the  configuration  item  has  fulfilled  the  specified  requirements. 
(2)  The  receiving  and  sending  systems  can  operate  on  the  entity  in  the  same  manner  with  the 
same  results  within  a  pre-defined  tolerance. 

Function  Modeling  —  A  description  of  a  system  in  terms  of  a  hierarchy  of  functions  or  activities, 
each  level  decomposing  higher  ones  into  greater  detail.  Functions  are  named  by  verbs;  nouns 
related  are  declared  as  inputs,  controls,  outputs,  and  mechanisms. 

Geometric  Element  (Generic)  —  An  instance  of  a  geometric  entity. 

Geometric  Group  —  A  group  of  geometric  entities  with  a  name. 

Geomet  c  '  'ndei  —  A  part  description  in  terms  of  its  underlying  geometric  elements.  The  model 
may  be  a  wireframe,  surface,  or  solid  model. 

Geometric  Pattern  —  A  circular  or  rectan'.ular  pattern  of  geometric  entities. 

Group  Technology  Code  —  An  alphanumeric  string  identifying  significant  characteristics  of  a 
product,  enabling  group  technology  applications.  Also  known  as  Part  Classification  Code. 

Include  File  —  PASCAL  source  code  from  another  file  or  library  included  on  the  compilation  of  a 
PASCAL  source  file. 

Input  Data  —  That  information  which  the  application  needs  to  supply  in  order  to  interrogate  or 
operate  on  the  model.  This  data  may  assume  only  these  forms  prescribed  by  the  PDDl  Access 
Software  specification. 

Inspection  Cycle  —  A  period  for  which  nondestructive  testing  inspection  requirer'ents  are 
defined. 

Inspection  Cycle  Zone  —  An  entity  that  is  composed  of  a  unique  combination  of  zone  and 
inspection  cycle. 

Inspection  Module  Operator  —  Refers  to  personnel  operating  RFC  cell(s). 

Instrument  Setting  Adjustments  —  Nondestructive  testing  parameter  adjustments  automatically 
accomplished  via  pre-  and  post-calibration  operations.  These  adjustments  have  to  be  accom¬ 
plished  within  a  predetermined  tolerance. 

Internal  Flaw  —  A  subsurface  anomaly. 

Internal  Flaw  Major  Characteristic  —  A  vector  determined  by  an  agreed  upon  method. 

Example  (1 ):  The  vector  of  greatest  magnitude  from  the  centroid  to  a  boundary 
of  the  anomaly. 

Example  (2);  A  vector  representing  the  major  axis  of  the  minimum  ellipsoidal 
envelope  encompassing  the  anomaly. 


4-12 


IU0AO2/I 


Cl  FTR560240001U 
September  1989 


Internal  Flaw  Tolerance  —  A  unique  combination  of: 

(a)  Internal  flaw  orientation  range. 

(b)  Serviceable  internal  flaw  tolerance  limits. 

(c)  Repairable  internal  flaw  tolerance  limits. 

Internal  Flaw  Tolerance  Umn  —  A  unique  combination  of: 

(a)  Maximum  diameter. 

(b)  Maximum  depth  below  surface. 

(c)  Maximum  thickness. 

Interpreted  Request  —  Input  data  which  has  been  appropriately  modified  to  conform  to  the 
PDDI  Access  Software’s  internal  data  representation  so  that  it  may  be  further  processed. 

Key  Attribute  —  An  attribute  or  combination  of  attributes  having  values  that  uniquely  identify 
each  entity  instance.^ 

Laminates  Representation  (Generic)  —  A  topology  in  which  an  object  is  represented  as  layers  of 
flat  material  of  known  thickness. 

Location  Tolerance  —  Location  tolerances  specify  the  allowable  variation  in  position  of  model 
features.  Location  tolerances  include  various  forms  of  position  tolerancing  conventions.  These 
are  (true)  position,  concentricity,  alignment,  rectilinear  location,  and  angular  location. 

Logistics  Support  —  The  function  of  procuring,  distributing,  maintaining,  replacing,  and 
repairing  material  in  support  of  a  delivered  product. 

Machine  Coordinate  Positions  —  The  probe  location  with  respect  to  machine  coordinates. 

Machine  Preset  Data  —  Machine  coordinate  adjustments  automatically  accomplished  via  pre- 
and  post-calibration  operations.  These  adjustments  have  to  be  accomplished  within  predeter¬ 
mined  tolerance. 

Metadata  —  Data  about  data.  Defines  the  physical  schema  and  record  formats  of  the  part  data. 

Metamodel  —  A  body  of  data  that  defines  the  characteristics  of  a  data  model  or  structure. 

Model  —  A  collection  of  PDD  that  is  transferable,  displayable,  accessible,  and  equivalent  to  a 
Part.  The  internal  representation  of  the  application  data,  as  initiated  and  organized  by  the  user. 
The  model  is  also  referred  to  as  the  Working  Form. 

Model  Network  Definition  —  The  set  of  rules  and  deflnitions  which  outline  in  detail  the  data 
structure  whereby  higher  order  entities  may  be  composed  of  lower  order  entities,  or  constituents, 
and  the  lower  order  entities  may  be  constituents  of  one  or  more  higher  order  entities. 

^  Integrated  Computer  Aided  Manufacturing  (ICAM)  Architecture,  Vol.  5,  Information  Modeling 
Manual  (IDEFl),  USAF  Report  No.  AFWAL-TR-81-4023,  June  1981,  p.  212. 
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Native  System  —  The  FDD  and  applications  in  a  format  that  is  unique  to  the  database  of  a  CAD 
system. 

Nondestructive  Testing  Parameters  —  Parameters  used  by  the  Eddy  current  and  ultrasonic 
instruments  (examples:  amplitude,  phase  angle,  gain,  threshold,  and  so  on). 

Nonconstructive  Feature  Representation  (Explicit  Feature  Representation)  ~  A  feature 
representation  that  at  least  partially  depends  on  a  declaration  that  a  face,  or  portion  of  a  face,  it 
“in”  the  featiu^e. 


Nondestructive  Testing  Personnel  —  Personnel  responsible  for  the  generation  of  scan  plans  and 
derivation  of  applicable  nondestructive  testing  instrument  settings  used  in  the  scan  plans. 

Nonshape  Data  —  Produce  definition  data  that  cannot  be  represented  by  shape  elements. 

Normal  Forms  —  Conditions  reflecting  the  degree  of  refinement  and  control  over  the 
relationships  and  entities  in  an  information  model. 

Numerical  Control  Program  (Complete  and  Proposed)  —  Set  of  program  instructions  used  to 
generate  a  probe  path. 

Orientation  Range  —  An  envelope  in  which  the  major  flaw  characteristic  must  lie. 

Parse  —  The  process  of  analyzing  input  strings  (records)  to  identify  fields  and  to  verify  that  the 
data  has  a  valid  format. 

Part  Blueprint  —  A  blueprint  provided  by  the  engine  manufacturer  of  a  particular  FIDO  engine 
disk. 

Physical  Schema  —  Internal  representation  of  data;  the  computer  view  that  includes  stored 
record  format  and  physical  ordering  of  stored  records. 

PID  File  —  A  PID  File  is  a  copy  of  the  Working  Form  filed  to  disk  for  temporary  storage.  The 
software  that  produces  this  capability  (PID  Code)  is  provided  as  an  interim  solution  while  a 
translator  to  the  native  database  is  in  development. 

Polynomial  Spline  —  A  parametric  spline  of  order  1,  2,  or  3  defined  by  a  set  of  N+1  points.  The 
spline  is  CX,  CY,  or  CZ  continuous  and  defined  by  coefficients  such  that: 

x(i)  -  AX,i,  +  BX(i)  •  S  +  CX(i,  •  S**2  +  DX,;,  •  S**3 

y(i)  -  AY,i)  +  BY^,  •  S  +  CY(i,  *  S«2  +  DY,;,  •  S**3 
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z(i)  -  AZ(i,  +  BZ(y  •  S  +  CZ(i,  •  S-2  +  DZ(y  •  S«3 
and  a  parameter  space  (Tq,  Tj,  ... 
where 

T(i)  <  -  u  <  - 

S  -  u  -  T^^ 

Position  Tolerance  —  A  position  tolerance  (true  position)  specifies  a  tolerance  zone  within 
which  the  feature  may  vary  in  any  direction. 

Post-processor  —  A  phase  of  the  translator  where  data  is  received  from  the  Exchange  Format 
and  is  converted  to  the  Working  Form. 

Pre-proco'^sor  —  A  phase  of  the  translator  where  data  is  taken  from  the  Working  Form  and  is 
converted  i  the  Exchange  Format. 

Primitive  Constu  ctive  Feature  Representation  (Generic)  —  A  constructive  representation  that 
is  noncompound  and  that  does  not  incorporate  another  feature.  Such  a  representation  must 
consist  solely  of  overt  construction  information.  Representation  of  a  through  hole  by  centerline 
and  diameter  is  an  example. 

Probe  Blueprint  —  Blueprint  of  Eddy  current  probe  supplied  by  the  probe  manufactiirer. 

Product  Definition  Data  —  Those  data  “explicitly  representing  all  required  concepts,  attributes, 
and  relationships”  normally  communicated  from  Design  throughout  Mant^acturing  and 
Logistics  Support.  The  data  include  both  shape  and  nonshape  information  required  to  fully 
represent  a  component  or  assembly  so  that  it  can  be  analyzed,  manufactured,  inspected,  and 
supported.  They  enable  downstream  applications,  but  do  not  include  process  instructions.  These 
data  are  not  always  finalized  at  the  design  release;  the  manufacturing  process  can  also  add  to  the 
product  model  or  generate  derived  manufacturing  product  models. 

Product  Life  Cycle  —  Includes  design,  analysis,  manufacturing,  inspection,  and  product  and 
logistics  support  of  a  product. 

Product  Model  —  A  computer  representation  of  a  product. 

Product  Support  —  The  function  that  interprets  customer  request;  for  information  and  can 
provide  the  technical  responses  to  the  customer  in  the  form  of  technical  orders  and  instructions. 

Proprietary  Part  Raw  Data  —  Formatted  dataset  containing  proprietary  data  defining  size(s), 
maximums,  and  location (s)  of  critical  flaw(s)  (dimensional  and  locational  tolerance). 

RAW.O  File  —  A  data  file  that  uses  a  bi-cubic  patch  surface  representation  to  define  the  surfaces 
of  an  airfoiL 

Ready  Status  —  Go/No-Go  decision. 
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Relation  —  A  logical  association  between  entities.^ 

Remount  Decision  —  Decision  to  remount  an  engine  disk. 

Replicate  Feature  Representation  (Generic)  —  A  description  of  a  feature  as  being  identical  to 
another  feature  except  for  location.  Mathematically,  a  replicate  feature  representation  consists  of 
the  identification  of  another  (necessarily  constructive)  feature  plus  a  transformation. 

Robot  Initialization  Parameters  —  A  set  of  nondestructive  testing  parameters  used  to  initialize 
the  robot  on  an  Eddy  current  or  ultrasonic  cell. 

Rotational  Sweep  —  A  sweep  in  which  the  swept  curve  is  rotated  about  a  line  (the  “centerline” 
of  the  sweep). 

Ruled  Surface  (Generic)  —  A  surface  defined  by  a  linear  blend  of  two  curves. 

Run  System  —  The  Translator  subpackage  which  provides  the  communication  interface 
between  the  user  and  the  pre/Post -processors. 

Run-Time  Subschema  —  A  subset  of  the  data  dictionary  information  used  at  run-time  by  the 
access  software  to  provide  field  data  and  check  data. 

Scan  Plan  —  Instructions  that  drive  an  inspection;  these  include  inspection  area  geometry, 
ordered  inspection  path  points,  inspection  probe  selection,  inspection  path  for  each  probe, 
mechanical  commands  that  allow  mechanical  manipulator  positioning,  instrument  setting,  and 
all  the  variables  needed  for  signal  processing  and  flaw  data  acquisition  during  inspection. 

Scan  Plan  Specifications  —  Standards  and  procedures  used  in  creating  Eddy  current  and 
ultrasonic  scan  plans  for  the  RFC  system. 

Schema  —  Formal  definition  of  information  structure.  See  Conceptual  Schema,  Physical 
Schema,  Run-time  Schema. 

Shape  —  The  physical  geometry  of  a  mechanical  part,  as  distinguished  from  a  computer 
description  of  tha'  geometry.  Where  the  difference  is  significant,  the  attitude  is  taken  that  shape 
is  nominal  or  basic,  with  shape  variations  of  tolerances  grafted  thereon. 

Shape  Data  —  Include  the  geometric,  topological  description  of  a  product  along  with  the 
associated  dimensional  tolerances  and  feature  descriptions. 

Single  Spatial  Probe/Transducer  Path  —  The  starting  and  ending  location  of  a  single  probe 
movement. 

Size  Tolerance  —  Size  tolerances  specify  the  allowable  variation  in  size-of-model  features. 
Independent  of  location.  Size  tolerances  include  circumferentud,  rectilinear  size,  and  angular 
size. 

^  Ibid.,  p.  214. 
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Solid  Geometric  Model  (Shape  Representation)  —  A  computer  description  of  shape.  The 
description  may  be  partial  in  the  sense  that  not  all  aq;>ects  of  part  shape  are  indicated.  For 
example,  a  body  of  revolution  representation  of  a  turned  part  may  not  describe  the 
nonazisymmetric^  aspects  of  part  geometry.  A  solid  model  must  be  complete  and  unambiguous 
in  the  sense  that  it  describes  a  single  volume  in  3-D  space. 

Solid  Modeling  —  The  creation  of  an  unambiguous  and  complete  representation  of  the  size  and 
shape  of  an  object. 

Source  Code  —  A  computer  program  written  in  some  language  which  is  processed  to  produce 
machine  code. 

Spline  —  A  piecewise  polynomial  of  order  K,  having  continuity  up  to  order  K-1  at  the  segment 
joints. 

Squirter  Blueprint  —  Blueprint  of  the  squirter  head  that  houses  the  ultrasonic  transducer. 

Subface  —  A  subface  is  a  bounded  portion  of  a  face.  It  is  defined  by  an  underlying  face,  exactly 
one  periphciy  closed  curve  and  zero,  one,  or  more  internal  closed  curves  that  represent  cutouts  or 
holes  in  the  region.  The  internal  closed  curve  must  not  touch  or  intersect  each  other  or  the 
periphery  closed  curve  and  must  be  entirely  contained  within  the  periphery  closed  curve. 

Surface  Flaw  —  A  surface  anomaly. 

Surface  Raw  Major  Characteristic  —  A  vector  determined  by  an  agreed  upon  method. 

Example:  A  vector  representing  the  major  axis  of  the  minimum  elliptical 
envelope  encompassing  the  anomaly  in  the  plane  of  the  surface. 

Surface  Flaw  Tolerance  —  A  unique  combination  of: 

(a)  Surface  flaw  orientation  range. 

(b)  Serviceable  surface  flaw  tolerance  limits. 

(c)  Repairable  surface  flaw  tolerance  limits. 

Surface  Raw  Tolerance  Limit  —  A  xuiique  combination  of: 

(a)  Maximum  length. 

(b)  Maximum  width. 

(c)  Maximum  depth. 

Sweep  Surface  —  Surfaces  formed  by  extruding  or  revolving  a  plana''  profile  in  space. 

Syntax  —  Grammar  A  set  of  rules  for  forming  meaningful  phrases  and  sentences  from  words  in 
a  vocabulary. 

*  Ibid.,  p.  211. 
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System  Computer  —  VAX  11/780  and  supporting  peripheral  hardware. 

System  Constraints  —  Those  hardware  and  software  environmental  constraints  which  will  be 
impos'jd  upon  the  PDDI  Access  Software  that  will  limit  its  implementation  and  implication.  An 
example  of  such  constraints  might  be  the  particular  compiler  used  to  compile  the  PDDI  Access 
Software  package. 

To-Be  —  The  future  condition  possible,  given  a  proposed  capability. 

Tolerance  (Generic)  —  The  total  amount  by  which  something  may  vary.  For  mechanical  product 
definition,  tolerances  can  be  shape  tolerances,  weight  tolerances,  flnish  tolerances  and  so  on.  In 
the  context  of  GMAP,  the  term  “tolerance”  used  alone  implies  shape  tolerance.  Other  forms  of 
tolerance  (nonshape)  are  explicitly  stated,  for  example,  “finish  tolerance.”  In  a  GMAP  product 
model,  tolerances  occur  without  dimensions.  As  in  the  Product  Definition  Data  Interface 
Program,  model  dimensions  are  implicit  in  the  model  geometry.  Therefore,  application  of  a 
tolerance  implies  a  specific  underlying  dimension  or  geometric  condition. 

Topology  —  A  data  structure  that  assembles  geometric  entities  (points,  curves,  surfaces)  into  a 
solid  geometric  model. 

Iransducer  Blueprint  —  Blueprint  of  ultrasonic  transducer  supplied  by  the  transducer 
manufacturer. 

Transfer  Data  —  The  data  required  to  make  an  exchange  of  data  between  systems  (i.e., 
delimiters,  record  counts,  record  length,  entity  counts,  numeric  precision). 

Translator  —  A  software  MECHANISM  that  is  used  for  passing  data  between  the  Exchange 
Format  and  Working  Form  of  the  PDD. 

Ultrasonic  Cell  —  Hardware  used  to  perform  ultrasonic  inspection  operation  (internal  flaws). 

Ultrasonic  Inspection  —  An  inspection  method  used  to  detect  surface  flaws  on  a  disk.  It  uses 
ultrasonic  waves  through  a  stream  of  water  to  send  and  collect  signals  concerning  an  area 
targeted  for  inspection. 

Ultrasonic  Scan  Plan  —  Interpreter  code  program  controlling  the  ultrasonic  inspection  of  a 
particular  geometry. 

Unbounded  Geometry  —  Geometry  represented  parametrically,  without  limits,  usually  by 
coefficients  to  a  defining  equation. 

Unigraphics  (UG)  —  A  computer  graphics  system. 

User  Function  (UFUNC)  —  An  interface  to  the  UG  database. 

Working  Form  —  Product  definition  data  information  in  machine-dependent  data  formats;  an  a 
memory  resident  network  model. 
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Zone  —  A  physical  area  of  the  disk  composed  of  zone  components. 

Zone  Component  —  A  subface,  face,  or  feature  that  constitutes  a  zone  or  element  of  a  zone. 


4.8.2  Acronyms  Used  In  GMAP 


ADB 

— 

Application  Data  Block  (also  referred  to  as  Attribute  Data  Block). 

AIMS 

— 

Automated  IDEF  Methodology  System. 

ANSI 

— 

American  National  Standards  Institute. 

ANT 

— 

Abstract  of  New  Technology. 

APT 

— 

Automatically  Programmed  Tools. 

ATP 

— 

Automation  Technology  Products. 

BOM 

— 

Bill  of  Materials, 

BOR 

— 

Body  of  RevoliMion. 

BPI 

— 

Bits  per  Inch. 

BREP 

— 

Boundary  Representation. 

CAD 

— 

Computer  Aided  Design. 

CAE 

— 

Computer  Aided  Engineering. 

CAEDS 

— 

Computer  Aided  Engineering  Design  System. 

CALS 

— 

Computer-aided  Acquisition  and  Logistics  Support. 

CAM 

— 

Computer  Aided  Sfiantifacturing. 

CAM-I 

— 

Computer  Aided  Manufacturing— International. 

CAPP 

— 

Computer  Aided  Process  Planning. 

CAS 

— 

C^led  Airfoil  System. 

CDM 

— 

Common  Data  Model. 

CDR 

— 

Critical  Design  Review. 

CDT 

— 

Oimponent  Design  Technology. 

CFSR 

— 

Contract  Fund  Status  Report. 

Cl 

— 

Configuration  Item. 

CIM 

— 

Computer  Integrated  Manufacturing. 

CLIST 

— 

IBM  command  list. 

CM 

— 

Configuration  Management. 

CMM 

— 

Coordinate  Measuring  Machine. 

C/SSR 

— 

Cost/Schedule  Status  Report. 

CWBS 

— 

Contract  Work  Breakdown  Structure. 

DBMS 

— 

Data  Base  Management  System. 

DCL 

— 

DEC  Command  Language. 

DDL 

— 

Data  Definition  Language. 

DEA 

— 

Digital  Equipment  Automatic. 

DEC 

— 

Digital  Equipmart  Corporation. 

DESO 

— 

(ICAM)  Architecture  of  Design. 

DJR 

— 

Design  Job  Request;  Drafting  Job  Request. 

DoD 

— 

Department  of  Defense. 

DS 

— 

Design  Specification. 

DSM 

— 

Design  Substantiation  Memo. 

EBCDIC 

— 

Extended  Binary  Coded  Decimal  Interchange  Code  (IBM  character  set). 

EC 

— 

Eddy  Current. 

ECO 

— 

Engineering  Change  Order. 

EDM 

— 

Electrical  Discharge  Machining. 
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EF 

— 

Exchange  Format. 

Eli 

— 

Engineering  Information  Index. 

EMD 

— 

Engineering  Master  Drawing. 

EPCS 

— 

Engine  Product  ConHguration  Support. 

ESA 

— 

Engineering  Source  Approval 

ESP 

— 

Experimental  Solids  Proposal 

FEDD 

— 

For  E^ly  Domestic  Dissemination. 

FEM 

— 

Finite-Element  Modeling. 

FOF 

— 

Factory  of  the  Future. 

FOS 

— 

Feature  of  Size. 

FPIM 

— 

Fluorescent  Penetrant  Inspection  Module. 

FSCM 

— 

Federal  Supply  Code  for  Manufacturers. 

GE 

— 

General  Electric. 

GMAP 

— 

Geometric  Modeling  ^plications  Interface  Program. 

GSE 

— 

Ground  Support  Equipment. 

HCF 

— 

High-Cycle  Fatigue. 

IBIS 

— 

Integrated  Blade  Inspection  System. 

IBM 

— 

International  Business  Machines. 

ICAM 

— 

Integrated  Computer  Aided  Manufacturing. 

ICOM 

— 

Input/Control/Output/Mechanism. 

ICS 

— 

Information  Computer  System. 

IDEF 

— 

ICAM  Definition. 

IDEFO 

— 

IDEF  Function  Modeling. 

IDEFl 

IDEF  Information  Modeling. 

IDEFIX 

— 

IDEF  Extended  Information  Modeling. 

IDEF2 

— 

IDEF  Dynamics  Modeling. 

IDSS 

— 

Integrate  Decision  Support  System. 

IEEE 

— 

Institute  of  Electrical  and  Electronics  Engineers. 

lEN 

— 

Internal  Engineering  Notice. 

IFS 

— 

Interface  Specification. 

IGES 

— 

Initial  Graphics  Exchange  Specification. 

IISS 

— 

Integrated  Information  Support  System. 

ILC 

— 

Improved  Life  Core. 

IMS 

— 

Information  Management  System. 

IPGS 

— 

(IBIS)  Inspection  Plan  Generation  System. 

IRB 

— 

Industry  Review  Board. 

IRIM 

— 

Infrared  Inspection  Module. 

ISO 

— 

International  Standards  Organization. 

ITA 

— 

Intelligent  Task  Automation. 

m 

— 

International  TechneGroup  Incorporated. 

ITR 

— 

Interim  Technical  Report. 

LCF 

— 

Low-Cycle  Fatigue. 

MAS 

— 

Model  Access  Software. 

MCAIR 

— 

McDonnell  Douglas  Corporation/McDonnell  Aircraft  Company. 

MFGO 

— 

(ICAM)  Architecture  of  Manufacturing. 

MRP 

— 

Materials  Requirements  Planning. 

NAD 

— 

Needs  Analysis  Document. 

MBS 

— 

National  Bureau  of  Standards. 

N/C 

— 

Numerical  Control. 
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NDE 

— 

Nondestructive  Evaluation. 

NDML 

— 

Neutral  Data  Manipulation  Language. 

NDT 

— 

Nondestructive  Test. 

NTSB 

— 

National  Transportation  Safety  Board. 

NVI 

— 

Name/Value  Interface. 

OOP 

— 

Optical  Gaging  Products,  Inc. 

PA/QA 

— 

Product  Assurance/Quality  Assurance. 

PD 

— 

Product  Data. 

PDD 

— 

Product  Definition  Data. 

PDDI 

— 

Product  Defmition  Data  Interface  Program. 

PDES 

— 

Product  Data  Exchange  Specification. 

PDL 

— 

Program  Design  Language. 

PED 

— 

Preliminary  Engine  Design. 

PI 

— 

Principal  Investigator. 

PID 

— 

PDDI  Interim  Database. 

PIES 

— 

Product  Information  Exchange  System. 

PMP/PMS 

— 

Program  Management  Plan/Project  Master  Schedule. 

PROCAP 

— 

Process  Capability. 

PS 

— 

Product  Specification. 

RFC 

— 

Retirement  for  Cause. 

RPM 

— 

Revolutions  per  Minute. 

SA-ALC 

— 

San  Antonio-Air  Logistics  Center. 

SAD 

— 

State-of-the-Art  Document. 

SD 

— 

Scoping  Document. 

SDL 

— 

Source  Data  List. 

SDS 

— 

System  Design  Specification. 

SL 

— 

Salvage  Layout. 

SML 

— 

Source  Material  Log. 

SOA 

— 

State-of-the-Art  (Siu^^ey). 

SOR 

— 

Surface  of  Revolution. 

SPC 

— 

Statistical  Process  Control. 

SPF 

— 

System  Panel  Facility. 

SQA 

— 

Software  Quality  Assurance. 

SQAP 

— 

Software  ^ality  Assurance  Plan. 

SRD 

S^'stem  Requirements  Document. 

SRL 

— 

Systems  Research  Laboratories. 

ss 

— 

System  Specification. 

STEP 

— 

Standard  for  the  Exchange  of  Product  Model  Data. 

STP 

— 

System  Test  Plan. 

TCTO 

— 

Time  Compliance  Technical  Order. 

TD 

— 

Technical  Data. 

TDCR 

— 

Turbine  Design  Cost  Reduction. 

TDR 

— 

Tool  Design  Request. 

TechMod 

— 

Technology  Modernization. 

TO 

— 

Technical  Order. 

TOP 

— 

Technical  and  Office  Protocol. 

TSO 

— 

Time-Sharing  Option  (IBM  term). 

UFUNC 

— 

User  Function. 

UG 

— 

Unigraphics. 
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UGFM 

—  Unigraphics  File  Manager. 

USA 

—  Unified  System  for  Airfoils. 

USAF 

—  United  States  Air  Force. 

UTC 

—  United  Technologies  Corporation. 

UTP 

—  Unit  Test  Plan. 

UTR 

—  Unit  Test  Reftort. 

UTRC 

—  United  Technologies  Research  Center. 

VAX 

—  Virtual  Architecture  Extended. 

VMS 

—  Virtual  Memory  System. 

WBS 

—  Work  Breakdown  Structure. 

WF 

—  Working  Form. 

WPAFB 

—  Wright-Patterson  Air  Force  Base. 

XIM 

—  X-Ray  Inspection  Module. 
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APPENDIX  A 

UPPER  LEVEL  MODEL  OF  RELATIONSHIPS  OF 
UFE  CYCLE  ACTIVITIES  FOR  TURBINE  BLADES  AND  DISKS 


The  objective  of  creating  the  GMAP  scoping  function  model  was  to  provide  an  indication  of 
the  scope  that  GMAP  has  in  the  product  life  cycL-  of  turbine  blades  and  disks.  The  GMAP 
scoping  function  model  was  developed  by  interviewini ;  l:ey  individuals  familiar  with  jet-engine 
design,  manufactiiring,  and  product  support.  The  data  obtained  during  these  interviews  were 
then  analyzed  to  produce  an  upper-level  GMAP  0  model.  Although  sufficient  data  were  collected 
through  these  interviews  to  decompose  and  analyze  the  resulting  GMAP/A-0  level  through 
several  levels,  only  the  GMAP  A-0  and  AO  levels  are  presented  here. 

The  GMAP  0  model  has  been  compared  to  the  Composite  View  DESO  and  MFGO  models. 
Comments  are  included  in  the  supporting  text  to  indicate  where  the  GMAP  0  concurs  with  or 
differs  from  the  DESO  and  MFGO  models. 

A  node  tree  diagram  is  presented  in  Figure  A-1.  This  diagram  illustrates  the  node  list  and 
indicates  which  functions  will  be  decomposed  further  during  the  detailed  part  modeling  walk¬ 
through.  GMAP  is  expected  to  have  primary  impact  on  the  areas  indicated. 


The  primary  objective  of  A-0,  Develop  and  Produce  Engine  Products  (Context)  is  to  provide 
engine  products.  A  secondary  objective  is  to  provide  support  to  the  users  of  those  engine 
products.  The  function,  as  shown  in  Figure  A-2,  fulfills  these  objectives  by  procuring  items  and 
then  directing  the  personnel,  material,  equipment,  and  facilities  necessary  to  develop  and 
produce  the  engine  products.  This  function  incorporates  all  the  engine  product  life  cycle 
activities  within  an  aircraft  engine  product  manufacturing  enterprise,  Pratt  &  Whitney  and  any 
suppliers  of  material  or  services  acting  as  contracted  extensions  of  Pratt  &  Whitney. 

This  function  is  performed  according  to: 

•  the  requirements  of  any  contract  existing  between  the  customer  and 
Pratt  &  Whitney, 

•  the  goals  and  policies  of  Pratt  &  Whitney; 

•  any  validated  suggestions  for  improvements  in  the  engine  product  arising 
from  its  use  or  performance. 


The  performance  of  the  function  is  the  responsibility  of  Pratt  &  Whitney  in  concert  with  its 
suppliers.  The  activities  included  within  this  function  generaUy  correspond  to  those  within  the 
Composite  View  architecture  upper-level  function  A-1  (Develop  and  Produce  Aerospace 
Product). 


A-1 
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A-2 


Figure  A-1.  GMAP  Node  Tree 
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This  function  model  was  developed  to  identify  functions  within  the  product  life  cycle  for 
Pratt  &  Whitney  turbine  blades  and  disks  (Context)  that  require  product  data  (Purpose). 
Because  of  the  numerous  reviews  that  the  model  underwent  prior  to  publication,  the  model 
reflects  the  consensus  view  of  the  GMAP  team  (Viewpoint). 

The  primary  objective  of  AO  Develop  and  Produce  Engine  Products  is  to  provide  engine 
products.  A  secondary  objective  is  to  provide  support  to  the  users  of  those  engine  products.  This 
function  fulfills  these  objectives  by: 

•  designing  engine  products; 

•  procuring  the  personnel,  material,  equipment,  and  facilities  necessary  to 
manufacture  the  engine  products; 


•  providing  support  to  the  user  for  the  engine  product; 

•  managing  the  design,  manufacture,  and  support  activities. 

The  first  three  of  these  activities  include  the  anticipated  engine  product  life-cycle  activities 
that  will  be  impacted  by  GMAP. 


The  function  is  performed  according  to: 


•  the  requirements  of  any  contract  existing  between  the  customer  and  Pratt  & 
Whitney; 


•  any  validated  and  approved  suggestion  for  improvement  in  the  engine  product 
arising  from  its  use  or  performance. 

The  activities  within  this  GMAP  architecture  upper-level  AO  function  generally  correspond 
to  those  within  the  (Composite  View  architecture  upper-level  function  A-01  (Develop  and 
Produce  Engine  Products),  as  shown  in  Figure  A-3. 


The  first  function,  Manage  Engine  Products,  is  responsible  for  evaluating  the  objectives 
and  policies  of  Pratt  &  Whitney  and  the  requirements  of  the  contract  between  the  customer  and 
Pratt  &  Whitney. 

Once  an  evaluation  has  been  accomplished,  management  direction  is  provided  to  control 
the  performance  of  the  design,  manufacture,  and  support  functions.  To  comply  with  this  charter, 
the  manage  function  participates  in  the  product  life  cycle.  In  response  to  product  requirements 
and  suggestions,  product  data  describing  the  capabilities  of  Pratt  &  Whitney  engine  products  are 
reviewed  by  management. 
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Fijfure  A-3.  A-0  —  Develop  and  Produce  Engine  Products 
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This  review  results  in  a  preliminary  definition  of  product  functional  requirements,  which  is 
passed  on  to  the  design,  manufacturing,  and  stpport  functions.  Once  a  conceptual  design  that 
potentially  incorporates  the  product  functional  requirements  for  the  engine  product  has  been 
prepared,  management  will  review  the  design  and  decide  whether  further  implementation  of  the 
design  concept  meets  Pratt  &  Whitney  objectives  and  policies.  If  the  answer  is  positive,  a  project 
authorization  including  budgetary  and  schedule  guidelines  will  be  produced. 

The  second  function.  Design  Engine  Product,  is  responsible  for  creating  engine  product 
designs  of  sufficient  detail  and  accuracy  that  the  GMAP/A3  function  (Manufacture  Engine 
Product)  can  use  them  to  develop  the  instructions  for  production.  The  activities  within  the 
design  function  include: 

•  developing  a  conceptual  and  subsequent  firral  design; 

•  producing  a  design  layout; 

•  adding  manufacturing  data  to  the  design  layout  to  produce  a  detailed  design 
drawing. 

This  function  is  governed  by  the  design  functional  requirements,  the  capability  of  the 
production  equipment,  and  management  direction. 

The  third  function,  Manufacture  Engine  Product,  is  responsible  for  performing  the 
activities  required  to  plan,  provision,  and  produce  the  engine  product.  With  this  function  are  the 
activities  of: 

•  planning  for  manufacture; 

•  establishing  budgets  and  schedules; 

•  creating  production  plans; 

•  providing  production  resources; 

•  procuring  material; 

•  producing  the  engine  products. 

The  primary  outputs  generated  are  those  of  the  manufactured  new  engine  and  engine  parts, 
manufacturing  data,  and  product  manufacturing  information.  Controls  over  the  function  include 
the  product  design,  the  manufacturing  requirements,  and  the  direction  and  authorizations 
provided  by  Pratt  &  Whitney  management. 

The  fourth  function.  Provide  for  Product  Support,  is  responsible  for  providing  customer 
support  for  the  engine  products.  Within  this  function  are  four  major  activities: 

•  providing  technical  support  in  the  form  of  instructions  relative  to  the  engine 
products; 

•  processing  customer  requests  for  additional  engine  parts; 

•  supplying  the  customer  with  ground  support  equipment  for  use  with  the 
engine  products; 


A-6 


Cl  FTR660240001U 
September  1989 

•  providing  additional  support  activities,  such  as  logistics  forecasting  warranty 
administration  and  incident  investigations. 

The  conduct  of  these  activities  is  guided  by  the  support  needs  of  the  customer  and  to  the 
support  requirements  as  delineated  by  Pratt  &  Whitney  management. 

During  the  A2  —  Design  Engine  Product  activity,  as  shown  in  Figure  A-4,  engine  product 
designs  (in  this  instance  turbine  airfoil  or  disk  designs)  are  created  and  provided  to  the  GMAP/3 
function  (Manufacttire  Engine  Product).  Specific  production  instructions  are  generated  from  this 
input.  Design  activities,  leading  to  the  creation  of  the  manufacturing  input  information  include: 

•  providing  analytical  support  studies  that  produce  a  frnal  design; 

•  development  of  conceptual  or  preliminary  designs  for  management  evalu¬ 
ation; 

•  integrating  the  mechanical  design  steps  to  produce  a  design  layout; 

•  performing  the  fmal  drafting  activities  of  adding  resulting  in  detail  drawings. 


Controls  over  the  function  include  the  product  design,  the  manufacturing  requirements, 
and  the  direction  and  authorizations  provided  by  Pratt  &  Whitney  management. 

The  activities  within  this  GMAP/A2  function  generally  correspond  to  those  within  the 
Composite  View  DES/AO  function  (Design  Product).  However,  a  logical  decomposition  of  the 
activities  within  Pratt  &  Whitney  requires  a  four-function  decomposition  for  the  GMAP/A2 
rather  than  the  three-function  decomposition  applied  to  DES/AO. 

The  first  function,  Develop  Conceptual  Design,  begins  the  product  life  cycle.  It  involves  the 
initiation  of  a  preliminary  study  based  on  new  product  functional  requirements.  These 
requirements  may  be  either  vague  or  specific.  In  either  instance,  however,  they  must  be 
investigated  and  evaluated  to  determine  the  validity  and  extent  of  its  impact. 

The  investigation  will  often  result  in  the  preliminary  and  component  design  groups  scoping 
the  extent  of  the  impact  and  t^e  benefits  of  the  requirement  change,  and  the  resulting  time  and 
costs  to  implement  the  change.  Product  design  criteria  are  supplied  to  the  Component 
Technology  groups  and  form  the  basis  for  the  initial  product  design.  This  design  will  be  used  by 
management  to  decide  whetlwr  the  project  should  be  approved.  The  design  will  also  be  used  to 
provide  the  Component  Technology  groups  and  the  Mechanical  Designer  with  a  base  for 
beginning  the  detail  design  layout. 

In  the  second  function,  Produce  Final  Product  Design,  the  aerodynamic,  durability,  and 
structures  groxips  produce  a  final  turbine  airfoil  design  for  the  mechanical  design  layout.  The 
Aerodynamic  group  identifies  candidate  turbine  blade  shapes  that  meet  the  functional 
requirements,  while  the  Durability  and  Structures  groups  address  such  design  elements  as  airfoil 
cooling,  component  life,  heat  transfer  characteristics,  and  stress  analysis. 
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Figure  A-4.  Design  Engine  Product 
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The  Aerodynamic  and  Durability  groups,  within  Component  Technology,  generate  the 
external  and  internal  contours  that  are  used  to  define  the  turbine  airfoils.  This  design  is  further 
optimized  using  the  results  of  streamline  analysis,  which  accounts  for  the  interaction  of  end-wall 
effects.  Technical  Data  (TD)  is  communicated  to  the  Structures  Group  for  evaluating  vibratory 
characteristics  and  to  Mechanical  Design  to  begin  the  part  layout. 

Several  iterations  may  result  from  these  analyses.  These  iterations  may  involve  component 
or  rig  testing.  The  Co'nponent  Technology  support  groups  will  conduct  the  tests  they  consider 
necessary  to  validate  .ae  design. 

When  the  final  design  satisfies  these  groups,  it  is  passed  to  the  Mechanical  Designer  and 
other  involved  project  groups  through  a  Florida  Technical  Data  Memorandum  (FTDM).  The  TD 
is  filed  in  the  Design  Job  Record  (DJR)  of  the  Mechanical  Designer.  The  Produce  Final  Product 
Design  process  is  simplified  for  turbine  disks,  involving  only  the  Mechanical  Design  and 
Structures  groups,  since  the  design  of  an  externally  cooled  symmetric  body  of  revolution  is  less 
complex.  The  Mechanical  Design  Group  identifies  candidate  turbine  disk  shapes  that  meet  the 
functional  wd  structural  life  requirements  while  the  Structures  group  addresses  fracture 
mechanics  co  ^siderations.  After  the  disk  design  has  been  jointly  optimized  by  Mechanical  Design 
and  Structure  fc*oups.  Mechanical  Design  begins  the  part  layout  and  Structures  group  issues  an 
FTDM. 

The  third  function.  Produce  Mechanical  Design,  includes  all  those  activities  that  result  in 
an  approved  design  layout,  which  will  satisfy  the  functional  requirements  established  by 
management.  These  activities  are  the  prime  responsibility  of  the  Mechanical  Designer  assigned 
to  the  project.  It  is  within  these  activities  that  the  final  product  design  is  analyzed  and  ultimately 
described  in  a  form  that  will  allow  for  its  approval  and  release  to  drafting.  The  design  package 
that  is  transferred  includes  the  layout  drawings  and  a  DSM.  Information  relating  to  quality  and 
to  manufacturing,  as  well  as  Engineering  Source  Approval  (ESA)  requirements,  is  added. 

The  fourth  function,  Provide  Detail  Drawings,  is  the  activity  that  results  in  the  creation  of 
formal  detail  drawings.  The  design  layout  package  is  combined  with  other  design  information 
and  historical  background  data.  This  information  provides  the  foundation  for  the  GMAP/A3 
function  (Manufacture  Engine  Product).  The  design  package  is  converted  to  maniifacturing 
instructions  that  will  enable  production  to  make  and  inspect  the  engine  product.  The  detail 
design  package  is  the  responsibility  of  the  Drafting  group,  who  first  converts  the  design  layout 
into  Engineering  Master  Drawings  (EMD)  for  blades  only. 

EMDs  provide  various  two-dimensional  cross-section  and  profile  views  of  a  particular  part. 
These  are  reviewed  by  the  Aerodynamics,  Durability,  and  Mechanical  Design  groups  to  verify, 
through  the  use  of  overlays,  that  the  design  is  the  same  as  the  original  design  approved  by  these 
groups.  These  EMDs  are  released  to  Manufacturing  as  soon  as  possible  to  minimize  the 
procurement  cycle  for  investment  casting  tooling. 

Detail  blade  casting  drawings  are  prepared  and  complete  cooling  hole  locations  are  precisely 
defined  for  manufacturing.  This  design  package  is  reviewed  and  approved  for  release.  The 
package  consisting  of  the  layout,  drawings,  EMDs  (airfoils  only)  and  associated  computer  files  as 
well  as  the  component  parts  lists,  is  sent  to  Engine  Product  Configuration  Support  (EPCS).  This 
group  is  responsible  for  the  maintenance,  reproduction,  and  distribution  of  the  detail  drawings. 


A-9 


tuatn/r 


Cl  FTR560240001U 
September  1989 


The  A3  Manufacture  Engine  Product,  as  shown  in  Figure  A-5,  includes  the  activities 
necessary  to  plan,  provision,  and  produce  turbine  engine  components.  Incorporated  are  the  major 
activities  of: 

•  planning  for  manufacture; 

•  establishing  budgets  and  schedules; 

•  creating  production  plans; 

•  providing  production  resources; 

•  procuring  materials; 

•  producing  the  engine-related  product. 

Generally,  each  of  the  activities  produces  an  output  that  becomes  a  control  over  other 
activities.  External  controls  over  the  manufacturing  function  are  the  product  design,  the 
production  capability  possessed  by  the  manufacturing  facility,  and  the  direction  provided  by 
management.  The  activities  within  this  GMAP/A3  function  generally  correspond  to  those  within 
the  Composite  View  MFG/AO  function  (Manufacture  Product). 

The  ftrst  function.  Plan  for  Manufacture,  is  concerned  with  developing  and  maintaining  the 
plan  that  will  support  the  manufacture  of  the  product.  Generally  considered  are  the  activities  of; 

•  reviewing  new  product  opportunities; 

•  developing  production  start-up  plans; 

•  integrating  all  plans  within  manufacturing; 

•  monitoring  performance; 

•  informing  management  of  program  status. 

This  activity  responds  to  production  requirements,  product  design  requirements,  and  the 
master  schedule,  as  a  feedback  from  the  budgetary  and  scheduling  function. 

The  second  function,  Make  and  Administer  Schedules  and  Budgets,  produces  schedules  and 
budgets  that  provide  adequate  coordination  among  the  various  functions.  This  activity  involves 
preparing  a  preliminary  schedule  and  cost  estimate  based  on  initial  manufacturing  plans  and 
then  refming  the  schedule  tmd  budget  as  production  details  and  bill  of  materials  are  developed. 
The  ultimately  produced  master  schedule  relates  to  the  final  production  plans.  Over  time,  this 
function  collects  actual  schedule  and  budget  data,  matches  these  to  plans,  and  adjusts  priorities 
as  necessary.  All  accomplishments,  expenditures,  exceptions,  and  warnings  are  supplied  to 
management  in  the  form  of  reports.  The  major  controls  for  these  activities  are  the  production 
requirements,  the  manufacturing  plan,  and  the  bill  of  materials. 

The  third  function.  Plan  Production,  relates  to  the  tactical  strategy  necessary  to  produce 
engine  products,  providing  manufacturing  instructions,  establishing  inspection  methods,  and 
producing  machine  tool  and  gage  defmitions.  The  major  activities  encompass: 

•  the  planning  and  scheduling  of  the  production  methods  definition  activit>, 

•  the  providing  of  manufacturing  instructions; 

•  the  establishing  and  documenting  of  the  inspection  instructions; 

•  the  developing  and  specifying  of  accompanying  tool  designs. 
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Also  provided  are  numerical  control  tapes,  computerized  coordinate  measuring  instructions, 
machining  instructions,  and  inspection  instructions. 

Items  that  provide  control  over  this  function  include:  the  detailed  design  package  from  the 
GMAP/A2  function  (Design  Engine  Products);  requirements,  related  to  capacity  and  capability 
within  the  production  facility;  and  the  quality  assurance  data  that  are  supplied  by  quality 
engineering.  This  function  at  Pratt  &  Whitney  differs  from  the  Composite  View  MFG/A3 
function  (Plan  Production)  only  to  the  extent  that  the  numerical  control  and  the  coordinate 
measuring  machine  tapes  are  produced  here  instead  of  in  the  MFG/A4  function  (Provide 
Production  Resources). 

The  fourth  function.  Provide  Production  Resources,  includes  the  activities  of  planning, 
provisioning,  and  acquiring  the  resources  for  the  GMAP/A36  function  (Produce  Engine 
Product).  This  function  provides  four  major  resource  outputs: 

•  facilities  to  house  the  production  process  and  support  services; 

•  equipment  to  transform  the  purchased  material  into  the  engine  products; 

•  tools  such  as  cutting  tools,  jigs,  fixtures,  and  gages  to  be  used  in  association 
with  the  equipment; 

•  trained  people  to  perform  the  production  tasks. 

The  interactions  between  this  function  and  the  other  functions  of  this  GMAP/A3  level  of 
Manufacture  Engine  Product  is  relatively  limited,  although  the  primary  controls  collectively 
affect  all  of  the  functions.  These  controls  include  the  manufacturing  plan,  the  schedules,  and  the 
equipment/tool  specifications,  all  of  which  are  outputs  from  other  Actions  within  GMAP/A3 
function  (Manufacture  Engine  Product). 

The  fifth  function.  Obtain  Manufacturing  Materials,  includes  all  phases  of  material 
acquisition  from  purchasing  through  in-house  storage  and  distribution.  Within  this  function,  the 
problem  of  meeting  the  material  needs  called  for  in  the  manufacturing  schedules  is  resolved  by 
considering  the  level  of  the  material  inventory  in  hand  and  the  material  on  order.  Any  deficiency 
leads  to  procurement  of  additional  materials  from  suppliers.  Also  within  this  function  is  the 
inspection  of  the  items  delivered  from  suppliers.  In-house  material  inventory  management 
identifies  material  availability,  distributes  material  when  requested,  and  provides  the  record¬ 
keeping  function. 

Outputs  from  this  function  include  procured  raw  material,  vendor-produced  components, 
and  material  inventory  records  date.  This  function  reacts  to  the  overall  controls  of  the  materials 
plan,  schedule,  and  budget  as  well  as  an  identification  of  critical  and  long/lead-time  items. 
Inventory  and  inspection  reports  supply  feedback  to  the  procurement  control  activity. 

The  final  function.  Produce  Engine  Product,  encompasses  those  activities  in  which  the 
provided  manufacturing  materials  are  transformed  into  the  engine  products,  using  resources  and 
plans  provided  by  the  foregoing  functions.  Engine  products  include  not  on>y  complete  engines 
but  also  items  to  meet  spare  part  orders  or  in'>’ontory  requirements.  Within  this  production 
function,  production  control  handles  the  scheduling  and  assignment  of  work  on  an  orderly  basis. 


A-12 


Cl  FTR560240001U 
September  1989 

Inspection  and  test  of  the  engine  product  to  checkout  conformance  to  specifications  before  the 
final  packaging  and  delivering  of  the  product  to  the  user  are  performed.  Controls  on  production 
include  the  parts  list  (bill  of  material),  the  schedule,  {the  master  schedule,  and  the  schedule  from 
production  control  in  Composite  View  MFG/A61  function  (Control  Production  Orders)],  and  the 
manufacturing  and  inspection  instructions. 

Product  data  in  the  form  of  graphic  and  text  descriptions  impact  each  of  the  six  functions 
within  the  GMAP/A3  function  (Produce  Engine  Product)  to  varying  degrees.  However,  it  is  only 
within  the  GMAP/A33  function  (Plan  Production)  that  the  GMAP  involvement  appears  to  be 
significant. 

The  A4  —  Provide  for  Product  Support  function,  as  shown  in  Figure  A-6,  encompasses  the 
major  activities  that  Pratt  &  Whitney  imdertakes  to  provide  support  for  its  engine  products. 
There  are  four  major  activities: 

•  providing  technical  support  relative  to  the  engine  products; 

•  processing  the  user  requests  for  spare  and  replacement  parts; 

•  supplying  the  user  with  requested  ground  support  equipment; 

•  providing  other  support  activities. 

The  four  activities  are  generally  performed  independently  of  each  other.  Governing  the 
performance  of  the  activities  are  the  support  needs  as  expressed  by  the  user,  and  the  support 
requirements  as  expressed  by  the  managers  of  the  engine  product. 

Neither  the  Composite  View  MFGO  nor  the  DESO  model  provides  a  decomposition  of  this 
function.  Consequently,  the  function  decomposition  provided  in  the  GMAP/0  model  reflects  the 
functional  activities  at  Pratt  &  Whitney. 

The  first  function.  Provide  Technical  Support,  uses  product  manufacturing  information 
and  transforms  that  function  into  product  technical  instructions.  This  activity  ie  done  in 
compliance  with  the  support  requirements.  One  of  the  most  prominent  of  the  product  technical 
instructions  is  the  Technical  Order  (TO).  Technical  Order  support  is  provided  at  three  different 
levels: 

1)  at  the  flight-line  level  where  the  engine  is  in  the  plane  and  is  covered  by  the 
airframe  T.O.; 

2)  at  the  intermediate  level  where  the  engine  is  in  the  engine  shop  for 
maintenance  and  limited  repair; 

3)  at  the  depot  level  where  the  engine  modules  are  replaced  and  repairs  are 
made  with  limited  disassembly  of  the  modules. 


A-13 


Cl  FTR560240001U 
September  1989 


A-14 


IUM02/7 


Figure  A-6.  A4  —  Provide  for  Product  Support 


Cl  FTR560240001U 
September  1989 


Technical  Order  support  is  also  organized  along  four  engine  lines: 

•  OME  (other  mature  engines  such  as  the  TF30,  J52,  JT8D,  etc.); 

•  FlOO; 

•  RLIO; 

•  Other  (other,  newer  engines  in  development). 

The  second  function,  Process  Engine  Needs,  is  concerned  primarily  with  ensunng  that  the 
engine  needs  of  the  user  are  satisfied  according  to  the  support  requirements.  This  function 
includes  the  processing  of  replacement  and  spare  engine  part  orders.  All  engine  part  orders  go  to 
East  Hartford  where  part  production  is  scheduled.  The  manufactured  engine  parts,  as  well  as  the 
fabricated  grotind  support  equipment  that  has  been  validated,  is  processed  through  this  function 
and  is  provided  to  the  user. 

The  third  function.  Provide  General  Support  Equipment,  is  responsible  for  developing  and 
supporting  special  tooling.  The  tools  supplied  are  considered  to  be  over  and  above  the  cost  of  the 
engine.  A  requirement  for  ground-support  equipment  must  be  acquired.  If  the  requirement  is  for 
special  support  equipment,  it  is  designed  within  the  function  with  the  resulting  design  being 
released  for  fabrication.  Once  fabricated,  the  support  equipment  is  validated  and  support 
equipment  instructions  are  generated.  The  equipment  and  instructions  are  then  made  available 
to  the  user  through  the  second  function  of  processing  user  engine  needs. 

The  fourth  function.  Perform  Other  Support  Activities,  encompasses  many  activities; 
however,  these  activities,  although  important,  would  not  be  influenced  by  the  GMAP.  They 
include: 


•  developing  logistics  support  analyses  for  new  engines; 

•  investigating  mishaps  and  incidents  related  to  an  engine  in  the  Geld; 

•  developing  and  administering  a  warranty  program; 

•  providing  product  support  resources; 

•  developing  forecasts. 

Because  this  function  will  not  be  decomposed  in  the  next  level,  these  activities  will  be 
discussed  in  greater  detail  in  this  level. 

The  USAF  requires  a  logistic  support  analysis  for  all  new  engines  and  for  major  engineering 
changes.  This  analysis  evaluates  product  life  cycle  costs  and  is  completed  early  during  the  engine 
design  phase. 

Because  there  is  no  military  equivalent  tv  the  civilian  NTSB  (National  Transportation 
Safety  Board),  Pratt  &  Whitney  is  sometimes  requested  by  the  USAF  to  participate  in  the 
investigation  of  incidents  (which  involve  no  loss  of  life  or  property)  or  mishaps  (which  involve 
the  loss  of  life  or  property)  related  to  the  engine.  Pratt  &  Whitney  will  review  the  incident  or 
mishap  in  the  Geld.  If  needed  engines  and  other  appropriate  pieces  will  be  brought  back  to  Pratt 
&  Whitney  for  investigation.  Engine  maintenance  records  are  also  checked  as  part  of  the  review. 

The  warranty  program  is  negotiated  with  the  user.  Once  established,  the  program  requires 
administration.  Investigations  are  performed  to  determine  the  validity  of  a  user  claim  against  the 
warranty.  A  key  element  of  the  investigation  is  determining  whether  the  deGcient  part  is  a 
Pratt  &  Whitney  part. 
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Pratt  &  Whitney  provides  for  engine  overhaul  at  their  Southington,  CT,  facility.  In 
addition,  Pratt  &  Whitney  has  field  representatives  at  the  USAF  overhaul  facilities  such  as  the 
one  in  the  San  Antonio  Air  Logistics  Center  at  Kelly  Air  Force  Base,  TX. 

Spare-parts  forecasting  is  an  important  activity  within  this  function.  A  five  year  horizon 
has  been  adopted  for  these  forecasts. 
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APPENDIX  B 

COORDINATION  WITH  OTHER  CIM  PROJECTS 

1.0  PRODUCT  DEFINITION  DATA  INTERFACE  PROGRAM 

McDonnel  Douglas  was  included  on  the  GMAP  team  to  provide  expertise  with  the  Prod'  ’;t 
Definition  Data  Interface  (PDDl)  program.  The  McDonnell  Douglas  personnel  under  contract  vj 
Pratt  &  Whitney  for  GMAP  were  the  same  people  responsible  for  the  PDDI  piogram.  TLis 
enabled  Pratt  &  Whitney  to  maintain  close  ties  with  PDDI.  Based  on  the  GMAP  needs  and 
requirements,  this  helped  Pratt  &  Whitney  decide  on,  and  implement,  appropriate  enhanceirer  ‘  s 
to  the  PDDI  system  components  to  complete  the  GMAP  design. 

Early  in  the  program,  McDonnell  Douglas  conducted  a  special  technical  workshop  to  give 
Pratt  &  Whitney  a  working  knowledge  of  the  components  of  the  PDDI  system.  McDonnell 
Douglas  also  assisted  in  getting  the  PDDI  software  loaded  and  on-line  on  Pratt  &  Whitney’s 
computer  network. 

Later  in  the  program,  McDonnell  Douglas’s  technical  efforts  became  fully  integrated  into 
the  program  as  they  undertook  their  assigned  responsibilities. 

2.0  INTEGRATED  INFORMATION  SUPPORT  SYSTEM 

The  Integrated  Information  Support  System  (IISS)  program  was  investigated  through 
attendance  at  meetings  and  presentations.  It  was  suspected  that  GMAP  should  be  aligned  with 
the  work  being  done  on  the  Common  Data  Model  (CDM). 

At  a  high  level  overview  of  the  IISS  program,  held  in  September  1987,  it  was  determined 
that  the  focus  of  GMAP  and  the  focus  of  IISS  were  quite  dissimilar.  GMAP  focused  on  Product 
Definition  Data  (PDD)  that  captured  the  design  intent  of  a  single  product,  and  are  used 
throughout  the  product  life  cycle.  GMAP  concentrated  on  the  exchange  of  PDD  and  provided 
mechanisms  to  accomplish  this.  IISS  concentrated  on  the  communication  &om  one  database 
format  to  another.  Typical  applications  using  IISS  did  not  use  PDD  The  IISS  focus  was 
primarily  on  business  oriented  product  data,  such  as  scheduling  and  inventory  control.  In 
addition,  IISS  did  not  support  graphics  required  in  GMAP. 

3.0  INTELLIGENT  TASK  AUTOMATION 

It  was  difficult  to  identify  a  point  of  contract  with  the  Intelligent  Task  Automation  (ITA) 
program.  Investigation  dealt  primarily  with  obtaining  documentation  on  the  work  done  on  the 
ITA  programs.  This  documentation  helped  GMAP  understand  the  needs  of  future  applications 
that  could  benefit  from  rich  PDD. 

4.0  FACTORY  OF  THE  FUTURE 

The  Factory  of  the  Future  (FOF)  project  ceased  to  exist  early  in  the  GMAP  project.  Had  it 
continued,  it  might  have  been  a  framework  for  GMAP  development  of  PDD  integration.  It  might 
also  have  helped  in  the  area  of  fmanre  and  other  administrative  areas. 
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5.0  STANDARDS  ORGANIZATIONS 

GPilAP  was  involved  extensively  with  the  various  standards  organizations.  Several  meetings 
and  dif>cussions  were  held  with  Mr.  B.  Smith  of  the  National  Bureau  of  Standards,  later  National 
Institute  of  Standards  and  Technology  (NIST),  to  discuss  the  possible  roles  of  the  GMAP  effort 
within  the  standards  community.  One  area  of  coordination  dealt  with  PDES.  Pratt  &  Whitney 
intended  to  help  extend  the  industry  standard  for  PDD  by  pushing  the  technology  in  this  area. 
The  intent  was  to  use  the  existing  PDDl  as  a  base  for  extending  PDD. 

Another  area  of  interaction  in  the  standards  community  dealt  with  IGES.  GMAP  personnel 
supported  the  e^ort  to  improve  IGES  and  worked  with  the  American  Society  of  Mechanical 
Engineers  to  update  the  existing  ANSI  Y14.26M  Standard  on  Digital  Representation  for 
C!ommunication  of  PDD. 

All  GMAP  team  companies  actively  participated  with  the  NIST  IGES/PDES  efforts.  This 
participation  spanned  the  full  spectrum,  from  membership  on  the  IGES  steering  committee,  to 
committee  chairpeople  and  members  of  working  committees.  As  work  progressed  on  GMAP,  the 
team  ensured  that  information  was  disseminated  to  the  appropriate  committees  within 
IGES/PDES.  This  was  accomplished  by  making  technical  reports  (based  on  Air  Force  approval) 
available,  by  presenting  technical  information  to  the  committees,  and  by  personal  interaction 
with  the  IGES/PDES  committees.  The  intent  was  to  share  technical  information  with  these 
{rToups  and  provide  needed  assistance. 

5.1  IGES/PDES 

•  In  July  1986,  two  members  of  the  Pratt  &  Whitney  GMAP  technical  team 
participated  in  an  IGES/PDES  conference  held  in  Seattle,  Washington.  They 
had  an  opportunity  to  both  review  and  discuss  issues  surrounding  PDD  with 
committee  members  and  to  report  GMAP  technical  progress.  In  addition,  the 
Air  Force’s  GMAP  Program  Manager  gave  a  presentation  on  the  Air  Force’s 
expectations  of  PDES.  The  exchange  of  technical  information  was  beneficial 
to  the  GMAP  effort. 

•  A  PDES/MPC  (Mechanical  Products  Committee)  meeting  was  held  at  Pratt 
&  Whitney  in  late  1986  to  review  the  PDES/MPC  IDEFlX  information 
model  that  the  committee  was  developing.  Pratt  &  Whitney  was  the  last  in  a 
series  of  companies  visited  prior  to  the  PDES/MPC  submission  of  its 
recommended  information  model  to  the  main  PDES  committee.  The  main 
purpose  of  the  visit  was  for  validation  of  the  model  in  its  current  state.  The 
PDES/MPC  meeting  concerned  the  approach,  technique,  interpretation,  and 
alternatives  to  the  respective  model  concepts.  Several  PDES/MPC  model 
entities  addressed:  approval  and  effectivity,  physical  interface,  products  made 
from  other  products,  and  mechanical  products  in  general.  The  PDES 
tolerance  or  form  features  models  were  not  yet  incorporated.  The  concensus 
was  that  the  project  currently  was  incomplete,  and  needed  to  be  extended  to 
complete  its  intent.  However,  this  topic  was  outside  the  realm  of  the  meeting. 

•  Program  representatives  from  Pratt  &  Whitney,  United  Technologies  Re¬ 
search  Center  (UTRC),  and  MCAIR  attended  the  October  1986  IGES 
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committee  meeting  in  Huntsville,  Alabama  to  exchange  information  with  the 
IGES  committee  concerning  issues  on  the  PDES  development  activities.  A 
question  was  raised  concerning  how  the  PDES  personnel  would  receive  the 
GMAP  schema  information.  It  was  concluded  ^at  the  PDES  group  would 
have  to  request  this  information  from  the  Air  Force.  As  part  of  the 
PDES/MPC’s  report,  it  was  decided  that  the  Peoria  project  would  continue, 
starting  10  November  1986.  Mr.  M.  Dunn  of  UTRC  agreed  to  organize  a 
special  interest  session  in  Peoria,  Illinois  dealing  with  features. 

•  In  November  1986,  a  workshop  concerned  with  initiating  PDES  modeling  of 
form  features  was  organized  and  chaired  by  Mr.  M.  Dunn  UTRC.  The  session, 
conducted  as  part  of  the  MPC  effort,  was  attended  by  representatives  from  12 
companies,  including  the  prime  GMAP  subcontractors,  McDonnell  Douglas 
and  ITI.  As  a  result  of  the  conference,  planning  for  a  concentrated  PDES 
effort  on  form  features  was  initiated. 

In  addition,  Mr.  M.  Dunn  and  Mr.  K.  Perlotto  fiom  Pratt  &  Whitney 
performed  substantial  work  aa.  PDEIS  shape  tolerance  modeling.  They 
reviewed  a  working  model,  and  suggested  refinements.  The  model  was 
“normalized”  by  Mr.  Perlotto,  and  a  candidate  “integration”  of  that  model 
with  the  mechanical  products  model,  was  developed  by  Mr.  Dunn. 

•  The  January’  1987  quarterly  meeting  of  the  IGES  organization  included  a  two 
day  session  of  the  Edit  committee,  where  each  discipline  committee  presented 
their  application  models  develgg>ed  for  PDES.  These  sessions  were  attended 
by  Mr.  M.  Dunn  and  Mr.  K.  Perlotto.  'Hie  plan  was  to  perform  a  model 
integration  on  these  application  models  to  create  an  “initial  testing  draft.” 

Subsequent  meetings  of  the  Logical  iMyer  Committee  evaluated  the  discipline 
committees’  evaluations  of  readiness  €or  the  integration  process.  Based  on 
this,  it  was  determined  that  the  integzsJion  for  the  initial  testing  draft  would 
be  termed  the  “resource  models”.  Resource  models  form  the  supporting 
foundation  for  other  models.  They  were  the  curves  and  surfaces  model,  the 
constructive  solid  geometry  fdSG)  and  boundary  representation  (BREP) 
solids  models,  and  the  shape  todecance  model. 

The  actual  integration  was  perforned  t3ie  week  of  26  January  in  St.  Louis, 

Missouri.  K.  Perlotto  attended  and  cvstributed  to  this  integration  process. 

The  integration  also  extrapolated  a  hierarchy,  or  taxonomy,  for  PDES,  as  the 
models  depicted  it.  This  structure  was  similar  to  the  GMAP  schema  and  the 
PODI  schema,  with  the  PDES  scope. 

The  Logical  Layer  Committee  and  oAters  noticed  that  the  discipline 
organization  of  committees  was  not  optiaial.  K.  Perlotto  and  others  suggested 
that  an  organization  along  data  class  JIanes  would  be  more  appropriate.  This 
suggestion  was  drafted  in  the  form  of  a  recommendation  from  the  Logical 
Layer  Committee  chairman  to  the  PDES  leadership. 

•  A  representative  from  the  GMAP  technical  team  attended  the  30  March  to 
3  April  1987  joint  meeting  of  subcommittee  ISO/TC184/SC4/WG1  STEP  and 
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the  PDES  organization  at  the  Airport  Hilton  in  West  Palm  Beach,  Florida. 

This  meeting  was  a  technical  coordination  meeting  between  the  ISO 
development  of  the  STEP  and  the  United  States’  effort  on  PDES. 

The  ISO  subcommittee  was  documenting  and  distributing  integration  meth¬ 
odology  plans  to  modelers  in  the  STEP  effort.  A  planning  model  was  applied 
for  this  purpose.  Application  modelers  did  not  model  interests  outside  their 
discipline,  but  interfaced  with  the  appropriate  group(s)  to  obtain  the  needed 
support  (the  modified  data  class  approach).  This  strategy  was  used  effectively 
in  the  GMAP  schema  development  process,  and  was  recommended  to  the 
PDES  Logical  Layer  Committee  by  GMAP  participants. 

File  Structure  Committee  SG3  and  the  ad  hoc  EXPRESS  committee  met 
jointly  for  several  days  to  discuss  the  problems  with  EXPRESS  and  the 
mapping  of  EXPRESS  to  the  file  structure.  Erperience  with  the  EXPRESS 
language  in  the  development  of  the  PDES  Initisl  Testing  Draft  and  in  the 
GMAP  schema  specification  tested  the  language  with  large,  complex  exam¬ 
ples.  These  exercise  i  uncovered  minor  problems  and  tested  the  c£^abilities  of 
the  language  for  its  i  itended  purpose.  These  experiences  precipitated  the  joint 
meeting  of  these  two  committees  to  discuss  these  issues. 

•  Personnel  from  ITI,  UTRC,  and  McDonnell  Douglas  participated  in  the 
initial  working  session  of  the  PDES  subcommittee  on  form  features  in  April 
1987.  The  session  was  hosted  by  ITI.  It  produced  a  substantial  “starter” 

IDEFlX  model  for  form  features  information.  Among  the  resources  of  the 
subcommittee  were  working  documents  from  GMAP.  These  were  approved 
for  public  release  by  the  Air  Force  to  permit  PDES  access. 

•  A  GMAP  representative  attended  the  quarterly  meeting  of  the  IGES/PDES 
organization  held  20-24  July  1987,  in  Monterey,  California. 

Highlights  of  the  meeting  included  a  presentation  by  Mr.  T.  Moffett  from 
Northrop  on  the  creation  of  an  industry  cooperative  to  accelerate  the 
development  of  the  PDES  Version  1.0  specification.  The  Logical  Layer 
Committee,  responsible  for  the  integration  of  reference  information  models 
into  a  single  PDES  specification,  laid  the  groundwork  for  the  development  of 
a  resource  model  for  Product  Structure  and  Configuration  Management. 

In  addition,  a  subcommittee  of  the  MPC  was  formed  to  create  a  model  of  form 
features.  This  work  was  initiated  by  Mr.  M.  Dunn  from  UTRC.  The  GMAP 
Form  Features  submodel  was  set  forth  as  a  starting  point.  Mr.  R.  Gale,  from 
D.  Appleton  Company  (DACOM),  presented  the  status  and  overview  of  the 
form  features  model  in  Mr.  M.  Dunn’s  absence  at  the  IGES/PDES  Monterey 
meeting. 

•  Mr.  K.  Perlotto  from  Pratt  &  Whitney  participated  in  a  1  week  working 
fle«‘!ion  fo'  *he  PDES  Form  Features  Committee  hosted  by  Mr.  M.  Dunn  of 
UTRC,  at  UTRC  in  F«st  Hartford,  Connecticut,  14-18  September  1987.  The 
committee’s  work  involved  the  review  of  the  information  modeling  effort  in 
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form  features  to  date,  and  the  continuation  of  that  work.  The  13  committee 
participants  represented  11  different  companies,  both  in  and  out  of  the 
aerospace  industry.  The  meeting  concentrated  on  the  refinement  and 
attribution  of  the  existing  information  model.  The  meeting  also  expanded  on 
areas  that  were  thought  to  be  incomplete  in  the  model. 

The  meeting  resulted  in  a  better  understanding  of  the  scope  and  content  for 
the  model  and  the  relationship  of  the  model  to  the  PDES  shape  area,  and  the 
stabilization  of  the  model  structure  and  content.  GMAP  representatives 
continued  to  contribute  to  the  mudeliug  its  documentation. 

•  Mr.  K.  Perlotto  from  Pratt  &  Whitney  attended  the  IGES/PDES/ISO  joint 
quarterly  meeting  held  at  the  Chase  Park  Plaza  Hotel  in  St  Louis,  Missouri, 

12-16  October  1987.  Mr.  Perlotto  concentrated  his  efforts  in  a  committee 
meeting  concerning  the  Logical  Layer,  which  was  actually  meeting  as  the  ISO 
Ad  Hoc  Committee  on  EXPRESS.  Issues  concerning  the  content,  use,  and 
intent  of  the  EXPRESS  language  for  information  modeling  were  debated. 

The  experiences  and  attitudes  gained  on  several  issues  through  the  GMAP 
utilization  of  the  EXPRESS  language  in  the  GMAP  Conceptual  Schema 
specification  were  conveyed  to  the  committee. 

•  Mr.  K.  Perlotto  participated  in  two  PDES  integration  workshops  held  at 
NIST  27-29  October  arid  30  November-4  December  1987.  These  meetinp 
were  organized  and  run  by  DACOM  under  the  PDES  assistance  clause  from 
the  PDDI  Extension  contract.  The  primary  purpose  of  the  meetings  was  to 
develop  an  integrated  PDES  IDEFlX  model  of  several  available  topic  and 
resource  information  models. 

The  work  in  the  first  meeting  was  partially  integrating  IDEFlX  models  called 
Shape/Size  Element  Group  (SSEG),  and  Product  Structure/Configuration 
Management  (PSCM)  models.  It  was  decided  to  manage  these  models  under 
JANUS. 

Attendance  was  essentially  the  same  at  the  second  meeting,  with  some 
notable  European  additions  fiom  the  International  Standards  Organization 
(ISO).  The  43  issues  raised  at  the  previous  meeting  were  addressed. 

•  Mr.  K.  Perlotto  attended  the  IGES/PDES  quarterly  meeting  11-15  January 
1988  in  San  Francisco,  California.  The  Manufacturing  Technology  Commit¬ 
tee  conducted  a  detailed  review  of  the  PDES  Tolerances  model.  Mr.  M.  Dunn 
from  UTRC  introduced  several  refinements  that  were  incorporated  into  the 
model. 

The  MPC  devoted  one  day  to  the  review  and  comment  of  the  PDES  Form 
Features  model  developed  by  M.  Dunn.  Primary  modelers  M.  Dunn,  and 
Mr.  S.  (kiUo,  also  from  UTRC,  presented  au  overview  of  the  GMAP  portions 
of  the  mode]  and  K  Perlotto  discussed  the  IDEFlX  to  EXPRESS  conversion 
process. 
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The  PDES  Technical  Planning  Committee  determined  that  the  integration 
group  would  be  accepted  as  the  Integration  Subcommittee  of  the  Logical 
Layer  Committee.  The  Integration  Subcommittee  decided  to  hold  a  integra¬ 
tion  working  meeting  19-22  February  with  the  chairpersons  of  the  committees 
in  attendance.  Mr.  K.  Perlotto  was  the  EXPRESS  resource  and  Ms.  Y.  Yang 
from  DACOM  was  the  facilitator. 

In  ad  hoc  EXPRESS  Committee  activity,  K.  Perlotto  met  with  Mr.  P. 
Kennicott  from  General  Electric,  representing  the  testing  draft,  and  both 
Mr.  N.  Shaw  and  Mr.  J.  Owen  from  the  University  of  Leeds  to  discuss  Mr. 

Shaw’s  and  Mr.  Owen’s  review  and  comment  of  the  latest  EXPRESS 
specification,  N177.  In  the  process  of  implementing  a  parser  for  syntax 
checking  EXPRESS,  Mr.  Shaw  and  Mr.  Owen  uncovered  many  inconsisten¬ 
cies  with  the  document.  A  consensus  was  reached  to  resolve  the  inconsisten¬ 
cies  and  the  details  were  forwarded  Mr.  D.  Schenck  from  McDonnell 
Douglas  for  review  and  inclusion  in  the  final  N177. 

•  'iHree  GMAP  team  members,  Mr.  K.  Perlotto,  Pratt  &  Whitney;  Mr.  M. 

Du.  1,  UTRC;  and  Mr.  V/.  Burkett,  McDonnell  Douglas;  attended  a  5  day 
PDEb  integration  workshop  held  at  the  Quality  Inn  in  Gaithersburg, 
Maryland  on  18-23  February  1988.  It  was  felt  by  those  in  attendance  that  this 
workshop  was,  by  far,  the  most  successful  technical  interaction  session  to 
date.  The  team  worked  to  develop  a  strategy  for  the  integration  of  the  various 
models  [tolerance,  solids,  form  features,  finite  element.  Product  Structure  & 
Configuration  Management  (PS/CM),  geometric  modeler,  and  GMAP].  The 
primary  area  addressed  involved  the  way  that  the  application  models  were  to 
access  the  resource  model  for  shape,  and  how  those  models  interfaced  to  the 
PS/CM  data. 

The  main  accomplishment  of  the  meeting  was  ttae  acceptance  of  the  GMAP 
schema’s  approach  to  the  generalization  of  shape  into  “real  things’’.  This 
approach  was  successfully  used  for  GMAP  schema  development  during  the 
integration  process  that  allowed  the  separate  data  class  models  to  reference 
geometry.  The  individual  topical  models  refer  to  categories  of  sh^  elements 
such  as  object,  volume,  area,  seam,  and  location,  which  are  real  things.  These 
real  things  can  have  many  representations,  in  any  of  the  shape  models. 

The  acceptance  of  this  GMAP  concept  and  approach,  and  its  adaption  to  the 
PDES  environment,  represented  a  milestone  in  technology  transfer.  A 
concept  developed  under  a  government  project  as  a  solution  to  a  problem  was 
accepted  as  an  attractive  solution  for  helping  the  development  of  a  national 
standard.  The  POES  integrators,  after  agreeing  to  follow  this  strategy, 
discovered  that  it  allowed  the  integration  of  shape  with  tolerances,  form 
features,  and  finite  element  modeling  models  without  much  difficulty.  The 
“real  thing’’  acceptance  represented  the  fruition  of  the  PDES  Shape-Size 
Element  Group  (SSEG)  concept. 

•  Mr.  Perlotto  and  Mr.  Dunn  also  attended  the  IGES/PDES/ISO  Joint 
Quarterly  Meeting  held  the  week  of  27  March  1988  in  Washington,  D.C. 
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Mr.  Dunn  presented  a  walkthrough  of  the  integration  core  model  developed  at 
the  PDES  February  workshop  that  was  based  on  using  the  GMAP  approach 
to  the  generalization  of  shape  into  “real  things”. 

The  GMAP  approach  solved  approximately  80  percent  of  the  issues  raised  at 
the  initial  integration  workshop.  In  general,  all  the  committee  chairs,  and 
model  owners  were  pleased  with  the  direction  that  the  integration  took,  and 
supported  the  full  implementation  of  the  concepts  in  PDES. 

Because  both  IDEFIX  and  EXPRESS  models  were  being  used  in  PDES 
work,  it  was  necessary  to  determine  if  the  IDEFIX  and  EXPRESS  of  a  model 
were  equivalent.  It  was  decided  to  assemble  an  ad  hoc  groiq>  (under  edit 
committee  request)  to  investigate  the  need  for  correlation  of  the  various  forms 
that  the  conceptual  models  would  take  in  the  specification.  This  ad-hoc  group 
was  led  by  Mr.  Perlotto. 

•  GMAP  personnel  attended  the  fourth  PDES  Integration  Workshop  the  week 
of  13-17  June  1988,  held  at  DACOM  in  Manhattan  Beach,  California.  It  was 
determined  that  the  Integration  Committee  would  product  the  portion  of  the 
PDES  specification  known  as  Volume  3.  This  document  would  contain  the 
integrated  IDEFIX  model  for  PDES. 

The  Integration  Core  Model,  which  represents  the  shape  representation 
interface  via  idealized  or  “real”  shape  concepts,  was  refmed  to  address  the 
outstanding  issues  against  it,  and  to  allow  further  capabilities.  The  changes  in 
the  model  did  not  affect  the  original  structure  or  concepts  that  the  model 
contained.  Mr.  K.  Perlotto  would  prepare  the  latest  EXPRESS  rendition  of 
the  model  and  forward  it  to  the  committee  for  inclusion  in  the  Volume  3 
specification. 

•  GMAP  personnel  attended  the  IGES/PDES/ISO  joint  quarterly  meeting  held 
in  Denver,  Colorado  at  the  Hyatt-Regency  Hotel  11-15  July,  1988.  Mr.  K. 

Perlotto  would  be  preparing  another  version  of  the  form  features  model  by 
Mr.  M.  Dunn,  from  the  United  Technologies  Research  Center  (UTRC);  and 
an  updated  version  of  the  Integration  (Dore  Model  would  be  available  before 
that  date.  Mr.  Perlotto  would  also  conduct  an  in-depth  review  of  all  aspects  of 
the  ITD  -  Denver  version. 

Integration  ([Committee  meetings  involved  an  in-depth  review  and  refinement 
of  the  current  model  due  to  issues,  concerns,  and  proposals  introduced  by 
M.  Dunn.  The  status  of  all  the  other  models  for  inclusion  were  reviewed.  A 
formal  documentation  standard  for  the  PDES  Volume  3  document  (IDEFIX 
models)  was  reviewed  and  adopted.  The  next  workshop  was  rescheduled  from 
the  week  of  22  August  to  the  week  of  8  August,  in  St  Louis,  Missouri,  in 
response  to  the  schedule  deadline  of  8-14  August  for  the  next  ITD. 
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•  The  fifth  integration  workshop  of  the  PDE^  integration  Committee  was 
attended  by  GMAP  personnel.  The  workshop  was  held  19-23  September, 

1988,  and  was  hosted  by  McDonnell  Douglas  Astronautics  Company  in 
Huntingtor.  Beach,  California. 

The  integration  workshop  addressed  all  issues  proposed  against  the  integra¬ 
tion  core  model.  In  over  3  days  of  discussion,  only  one  issue  resulted  in  the 
deletion  of  two  entities.  Two  new  entities  were  created.  This  attests  to  the 
acceptance  and  stability  of  the  integration  core  model.  The  group  also 
addressed  the  “complete  issues”  log  of  the  committee,  and  disposed  of  dozens 
of  issues  contained  there,  leaving  a  few  open  for  future  reminders. 

•  The  IGES/PDES/ISO  joint  quarterly  meeting,  held  17-21  October  1988,  in 
West  Palm  Beach,  Florida,  was  attended  by  GMAP  personnel.  The  state  of 
the  PDES/Standard  for  the  Exchange  of  Product  Model  Data  (STEF) 
specification  of  the  West  Palm  Beach  version  of  the  PDES  Testing  Draft,  and 
accompanying  documents,  would  be  submitted  to  the  parent  body  in  ISO  at 
the  28  November-2  December  meeting  in  Tokyo,  Japan.  The  parent  body  of 
ISO  TC184/SC4/V/G1  would  receive  the  STEP  specification,  physical  file 
format,  EXPRESS  language,  mapping  from  EXPI^SS  to  physical  file,  and 
the  integrated  reference  model  documents. 

•  GMAP  personnel  reviewed  Standard  for  the  Exchange  of  Product  Model  Data 
(STEP)  documents  N301  and  N302,  a  proposal  for  STEP  geometry,  and  a 
proposal  for  STEP  Geometry,  Topology,  and  Sh^  Representation.  These 
proposals  have  modifications  since  the  Denver  '88  PDES  draft  proposal. 

GMAP  personnel  determined  a  strategy  for  PDES  implementation,  given  that 
the  specification  is  in  the  process  of  continual  modification  and  refmement. 

GMAP  personnel  felc  that  it  would  be  more  productive  to  expand  the  PDES 
subset  to  include  more  complicated  defined  types  and  entities.  This  would 
further  test  the  system  components’  ability  to  handle  PDES  when  the 
Integrated  Product  Information  Model  (IPIM)  is  finalized. 

•  An  IGES/PDES  quarterly  meeting  was  held  15-20  January  1989  in  San 
Diego,  California  The  submittal  of  STEP  to  the  ISO  in  December  1988  was 
accepted  by  the  ISO  for  registration  as  a  draft  proposal  The  ISO  secretariat 
circulated  a  letter  ballot  to  include  voting  by  each  member  country  on  each 
clause  and  each  section  of  the  draft  proposal. 

In  another  area,  it  was  publicly  declared  by  Mr.  Brad  Smith  that  IGES 
development  will  continue  beyond  the  release  of  IGES  V5.0.  There  had  been 
statements  in  the  past  that  the  IGES  project  would  terminate  with  the  V5.0. 

•  In  accordance  with  the  statements  of  work  for  the  GMAP  contract,  the  Air 
Force  approved  the  technology  transfer  of  GMAP  software  and  architecture 
to  the  PDES  National  Test  Bed  Project  at  NIST.  The  task  will  involve  the 
establishment  of  a  Pratt  and  Whitney  employee  as  a  NIST  research  associate 
at  NIST.  The  work  will  include  the  installation  of  the  GMAP  software  at 
NIST  to  provide  an  environment  in  which  PDES  testing  may  occur.  In 
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addition,  there  will  be  some  migration  tasks  to  move  a  GMAP  demonstration 
application  to  execute  in  the  PDES  environment,  therefore  providing  proof- 
of-concept  that  the  product  data  technology  developed  under  GMAP  is 
applicable  to  PDES.  The  duration  of  this  support  to  NIST  is  to  be  6  man- 
months. 

5.2  ANSI  Y14.26M  SUBCOMMITTEE 

The  IGES/PDEIS  groups  are  working  on  the  development  of  specifications.  The  work  being 
done  by  these  groups  is  passed  to  the  appropriate  organization  sanctioned  to  produce  national 
standards.  The  prime  organization  related  to  GMAP  was  the  American  National  Standards 
Institute  Y14  subcommittee  26M.  This  subcommittee  was  chartered  to  coordinate  with 
interested  groups  to  review  and  obtain  approval  for  a  standard  for  information  structures  to  be 
used  for  the  digital  representation  and  communication  of  PDD.  The  ANSI  Y14.26M  standard 
reflected  the  technology  level  of  IGEs  version  1.0,  which  was  established  as  a  standard  in  1981. 

This  ANSI  subcommittee,  inactive  for  a  period  of  years,  was  reactivated  during  the  PDDI 
program  to  upgrade  the  existing  standard  to  reflect  the  developments  within  the  IGES/PDES 
committees.  The  first  major  undertaking  by  the  reactivated  committee  was  that  they  would 
pursue  upgrading  the  existing  standard  to  reflect  the  IGES  version  3.0.  This  was  expected  to  take 
at  least  13  months,  implying  that  a  new  standard  should  be  established  sometime  after  August, 
1987.  The  next  step  for  this  committee  was  to  work  with  the  NIST  PDES  groups,  and 
Government  progr^s  such  as  GMAP,  to  begin  the  process  of  taking  this  specification  forward 
for  standardization.  ANSI/GMAP  Coordination  activities  are  described  below. 

•  In  June  1986,  ANSI  subcommittee  Y14.26M  met  to  review  IGES  version  3.0 
and  to  submit  the  new  specification  to  ANSI  to  begin  the  public  balloting 
process  to  obtain  acceptance  of  this  q^ecification  as  a  standard.  Two  members 
of  the  GMAP  team  attended  this  meeting;  Mr.  B.  Birchfield  fi^m  McDonnell 
Douglas,  who  was  the  chairman  of  the  Y14.26M  subcommittee,  and  Ms.  L. 

Phillips  from  Pratt  &  Whitney,  who  was  a  member  of  the  subcommittee. 

•  Pratt  &  Whitney’s  GMAP  Program  Integrator,  Ms.  L.  Phillips,  attended  the 
ANSI  Y14.26  meeting  in  Sarasota,  Florida,  on  1-2  October  1987.  This  was  a 
joint  meeting  with  the  ANSI  Y14  main  committee.  During  this  meeting,  it  was 
reported  that  the  ANSI  Board  of  Standards  approved  the  ANSI/American 
Society  of  Mechanical  Engineers  (ASME)  Y14.26M-1987  standard  based  on 
IGES  Version  3.0  on  2  September  1987. 

Another  major  item  discussed  at  this  meeting  was  the  investigation  of 
alternate  approaches  to  help  resolve  the  length  of  time  it  takes  for 
standardization.  An  action  item  firom  the  June  1987  meeting  was  a  survey  of 
ANSI  Y14.26  subcommittee  members  on  issues  surrounding  the  standardiza¬ 
tion  activities  and  the  issue  of  reorganization  of  the  Y14/Y14.26  committees. 

The  findings  of  this  survey  were  presented  at  this  joint  meeting.  It  was 
recommended  that  ANSI  Y14  undertake  a  study  to  review  the  scope  of  Y14 
committees  activities  to  provide: 

•  recognition  of  continuing  need  for  existing  standards, 

•  recognition  of  new  concepts  and  new  technologies, 

•  coordination  of  complementary  standards  development. 
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As  a  result,  an  ad-hoc  commi^^tee  was  formed  to  address  these  issues 
consisting  of  members  from  both  the  Y14  main  committee  and  the  Y14.26 
subcommittee.  Pratt  &  Whitney’s  GMAP  Program  Integrator,  Ms.  L.  Phillips 
chaired  this  ad-hoc  committee. 

•  Ms.  L.  Phillips,  and  McDonnell  Douglas’s  Program  Manager,  Mr.  H.  Ryan, 
attended  the  ANSI/American  Society  of  Mechanical  Engineers  (ASME) 

Y14.26  meeting  held  in  Albuquerque,  New  Mexico,  on  18*19  January  1988. 

Ms.  Phillips  gave  a  presentation  on  the  current  status  of  the  GMAP  contract 
and  Mr.  Ryan  showed  the  PDDI  Extension  end  of  contract  videotapes  to  the 
group.  The  main  focus  of  the  meeting  was  to  revise  the  scope  of  Y14,  the 
possible  reorganization  of  Y14,  and/or  Y14.26,  and  the  coordination  of  efforts 
in  the  electrical/electronics  standards  area. 

The  ad-hoc  committee  on  reorganization  issues  gave  a  presentation  on  its 
study.  The  group  continued  to  work  on  the  creation  of  a  new  scope  for  the  Y14 
main  committee  that  would  encompass  the  development  and  maintenance  of 
national  standards  for  product  data  and  related  control  systems  needed  to 
support  the  life  cycle  of  the  product.  The  scope  would  support  standards 
regardless  of  the  source  medium  (Le.,  paper,  film,  and  digital).  The  source 
medium  issue  appeared  to  be  the  root  of  most  problems  in  the  Y14  because 
only  Y14.26  appeared  to  address  the  digital  issues.  Strategies  included 
discussions  with  the  IGES/PDES  communities  to  form  stronger  ties  between 
the  creators  of  the  specifications  and  the  standardization  organizations. 

Another  topic  of  interest  was  the  planning  meeting  for  a  series  of  workshops 
on  mechanical  tolerancing  being  proposed  by  ASME  to  the  Nationed  Science 
i-ouiioation  lOt  lunding.  These  workshops  acdrcsseu  the  identification  of 
basic  and  generic  issues  dealing  with  computer  representation  of  mechanical 
tolerancing  to  permit  unambiguous  communication  between  design,  manufac¬ 
turing,  quality  control  and  inspection,  and  total  field  application.  The  overall 
goal  of  the  project  was  to  describe  the  state-of-knowledge  of  mechanical 
tolerancing  and  to  suggest  priority  areas  of  research  required  by  industry  and 
government.  To  ensure  that  the  planners  of  this  workshop  weie  aware  ui  ihe 
PDDI  and  GMAP  work  in  this  area,  as  well  as  the  IGES/PDES  work,  L. 

Phillips  and  H.  Ryan  offered  to  provide  a  representative  of  the  PDDI  and/or 
GMAP  contracts  to  this  planning  session.  Mr.  M.  Dunn  from  UTRC  was 
selected  to  attend.  The  first  planning  session  took  place  on  27-28  January 
1988. 

•  Ms.  Linda  Phillips  and  Mr.  Jack  Irvine  attended  the  ANSI  Commit¬ 
tee/American  Society  of  Manufacturing  Engineers  (ASME)  Y14.26  meeting 
held  in  Milpitas,  Caltfomia,  on  13-15  April  1988.  Ms.  Phillips  was  «q)proved  as 
the  new  Chairman  of  the  committee.  She  is  serving  from  April  1988  through 
May  1991.  It  was  hoped  that  during  this  time  a  version  of  PDES  will  be 
submitted  to  the  committee  for  standardization. 

The  A{»ii  meeting  focused  primarily  on  obtaining  the  status  of  the 
documentation  of  the  new  ANSI/ ASME  Y14.26  1987  standard  (IGES  Version 
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3.0).  Publication  of  the  standard  has  been  held  iq>  due  to  editorial  corrections 
and  artwork.  The  group  also  discussed  the  need  to  test  PDES.  It  was 
determined  that  development  of  a  test  plan  was  imperative.  Ms.  Phillips 
contacted  NIST,  the  CALS  office,  and  the  PDES  Cooperative  to  determine 
what  test  plans  these  orgsmizations  had. 

•  Ms.  Linda  Phillips  and  Mr.  Jack  Irvine  attended  the  ASME/ANSI  Y14.26 
meetings  held  4-5  August  and  3-4  October  1988.  The  August  meeting  focused 
primarily  on  reviewing  MIL-D-28000,  harmonization  activities,  and  PDES 
testing.  The  focus  of  the  October  meeting  was  on  IGES  Version  4.0 
standardization,  a  technical  report  on  PDD  and  Interactive  Computer 
Graphics  Systems,  and  the  findings  of  the  ASME  Tolerancing  workshop. 

•  Ms.  Linda  Phillips  attended  the  ANSC/ASME  Y14.26  meeting  held  in  San 
Diego,  California,  on  12  and  13  January  1989.  The  primary  focus  of  the 
meeting  was  on  reviewing  the  IGES  Version  4.0  standardization  activities  and 
recent  developments  regarding  PDES.  Other  items  discussed  were  DMIS 
standardization  and  the  mathematization  of  Y14.5. 

Developments  regarding  PDES  are  of  prime  interest  to  the  GMAP  communi¬ 
ty.  At  the  ISO  meeting  in  Tokyo  on  28  November  1988,  PDES  was  voted  to 
the  status  of  an  ISO  working  draft.  A  3  month  comment  period  will  begin  in 
March.  The  l?O0  page  document  may  be  ordered,  for  a  fee,  from  the  National 
Technical  Information  Services  at  (703)  487-4650.  Although  PDES  is  under 
comment  in  the  ISO  community,  the  PDES  organization  continues  to  mature 
the  specification  for  submittal  to  ANSI  for  consideration  as  an  American 
National  Standard.  The  time-frame  for  this  submittal  has  not  yet  been 
determined.  It  is  not  expected  to  occur  xintil  early  1990. 

6.0  CAM-1 

Pratt  &  Whitney  held  several  meetings  with  Mr.  P.  Downey  of  CAM-I  to  review  areas  for 
coordination  efforts.  It  was  determined  that  it  would  be  beneficial  to  coordinate  efforts  in  th® 
area  of  applications  interface.  GMAP  work  to  define  the  minimum  requirements  for  a  geometric 
modeler  was  considered  of  interest  since  it  would  help  CAM-I  define  the  functional  requirements 
for  a  modeler.  This  work  also  helped  determine  the  role  of  the  access  software  in  GMAP.  These 
meetings  also  led  to  the  inclusion  of  a  demonstration  of  an  interface  into  DMIS  in  the  GMAP 
end  of  contract  demonstrations. 

7.0  COMPUTER-AIDED  ACQUISITION  AND  LOGISTICS  SUPPORT 

•  Linda  Phillips  presented  a  GMAP  overview  at  a  NIST  meeting  on  CALS 
initiatives  24-25  June  1986.  The  CALS  program  has  the  objective  of 
integrating  the  design,  manufacturing  and  logistics  functions  through  the 
efficient  application  of  computer  technology.  CALS  has  the  additional  goal  of 
developing  a  unified  interface  with  industry  for  the  exchange  of  technical  data 
in  digital  form. 
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The  presentation  focused  on  the  need  to  electronically  transfer  complete 
product  data  and  bow  this  would  benefit  the  logistic  support  community.  It 
was  noted  that  many  of  the  same  functions  that  occur  in  5eld  support  have 
been  accomplished  in  the  design  and  manufacture  of  a  product  The  ability  to 
transfer  and  use  applicable  product  data  models  would  support  the  CALS 
goals  of  reducing  paper,  and  also  make  efficient  use  of  the  electronic  media  to 
obtain,  maintain,  and  produce  these  important  data. 

•  GMAP’s  liaison  for  subcontractors,  Mr.  Jack  Irvine,  attended  a  NIST 
meeting  in  January  1987  that  included  a  CALS  workshop.  The  purpose  of  the 
workshop  was  to  get  recommendations  from  industry  on  selecting  “core” 
requirements  for  standards  that  would  support  the  development  of  digital 
representations  and  archiving  graphics  data. 

Rockwell  and  Grumman  both  described  their  experiences  transferring 
t  'gineering  drawings  to  automated  publications  systems  using  digitizers, 
IGl'S  conversions,  and  teit/graphics  mergers.  IGES  conversions  were  not 
cost-eJective  nor  were  they  accurate.  The  Society  of  Automotive  Engineers 
(SAE)  was  working  on  validation  techniques  for  IGES  software  implementa¬ 
tions  with  clear  definition  of  the  level  of  entity  support. 

Raster  transfer  of  data  appeared  to  be  more  cost-effective  when  used  by 
technical  publications  groups  than  vector  data.  Technical  publications  do  not 
require  the  accurate  geometry  that  is  necessary  for  manufacturing,  but  can 
use  compressed  raster  displays  that  can  be  edited  for  removing  dimensions 
and  inserting  text. 

There  was  evidence  of  growing  confidence  in  the  services  that  delivery  of 
technical  orders,  maintenance  data,  and  logistics  information  can  optimally 
be  received  from  contractors  in  raster  form  using  optical  disk  systems. 
Standard  MIL-STD-1840  was  issued  by  the  Department  of  Defense  (DoD)  to 
describe  the  rules  for  the  method  of  electronic  delivery. 

•  The  Pratt  &  Whitney  GMAP  Program  Manager,  Mr.  Richard  Lopatka, 
attended  a  CALS-initiated  DoD  Cooperative  meeting  for  PDES,  held  19  June 
1986  in  Washington,  D.C.  Many  aerospace  companies  attended.  A  prospectus 
was  put  forward  by  an  ad  hoc  group  to  establish  an  organization  chartered  to 
accelerate  the  development  of  PDES.  Companies  involved  in  this  effort 
include  Northrop,  Boeing,  Grumman,  and  McDonnell  Douglas. 

•  Mr.  Jack  Irvine,  GMAP’s  supplier  liaison,  attended  a  CALS  workshop  at 
NIST  in  Gaithersburg,  Maryland  in  September  1987.  Year  end  presentations 
were  made  on  the  progress  CALS  had  made  in  defining  the  electronic  transfer 
of  technical  documentation.  CALS  was  expected  to  be  a  contractual  line  item 
in  at  least  four  "^ajor  weapon  systems  contracts  by  1990. 
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8.0  INTEGRATED  DESIGN  SUPPORT  SYSTEM 

In  late  1986,  members  of  Pratt  &  Whitney  GMAP  office  met  with  the  Pratt  &  Whitney 
member  of  the  IDS  Technical  Advisory  Group  (TAG)  to  obtain  a  briefing  of  the  IDS  program. 

The  IDS  program  focused  on  the  capture,  management,  and  communication  of  technical 
data  from  design  through  logistics  operations.  The  IDS  program  was  also  concerned  with  data 
models,  but  its  primary  work  was  in  data  management,  networks,  communications,  standardiza¬ 
tion,  and  data  security. 

GMAP  complemented  the  IDS  program  by  defining  the  PDD  schema  needed  to  support  the 
life-cycle  applications;  i.e.,  GMAP  was  helping  to  define  the  PDD  that  would  be  standardized  by 
PDES  efforts.  The  IDS  program  was  defining  the  environment  and  architecture  that  would 
access,  control,  and  manage  this  PDD  information.  Tde  IDS  program  had  developed  a  Product 
Cxintrol  model.  GMAP  developed  a  PDD  model.  Within  the  GMAP  PDD  schema  structure,  the 
two  programs  overlap  at  the  GMAP  Administrative  and  Assembly  level. 

Mr.  Richard  Lopatka  attended  the  TAG  meeting  for  the  IDS  program  held  in  Dayton,  Ohio 
on  7  and  8  April  1987  and  gave  a  presentation  on  the  technical  status  of  GMAP. 

9.0  OTHER 

•  As  part  of  the  GMAP’s  efforts  to  transfer  information  to  the  industrial 
community,  two  program  members  participated  in  a  Society  of  Manufacturing 
Engineering  (SME)  workshop  on  data  exchange  in  March  of  1986.  Mr.  Robert 
Lessard  from  UTRC  and  Pratt  &  Whitney’s  GMAP  Technical  Coordinator, 

Mr.  Ralph  Disa  authored  a  paper,  “Identification  of  Product  Definition  Data 
in  a  Manufacturing  Enterprise  —  A  Case  Stud”.  The  report  detailed  program 
methodology  for  obtaining  a  clear  understanding  and  use  of  PDD  as  it 
pertains  to  the  life  cycle  of  complex  structural  components  of  jet  engines.  This 
paper  also  gave  a  briefing  on  GMAP’s  technical  progress  using  the  methodolo¬ 
gy- 

•  Mr.  (jeorge  Leistensnider  from  Pratt  &  Whitney  presented  the  goals  and 
objectives  of  the  GMAP  program  to  the  Forging  Industry  Association  on 
12  June  1986.  This  presentation  focused  on  the  anticipated  benefits  of  GMAP 
to  the  forging  community.  The  presentation  was  well  received  and  a  number 
of  companies  expressed  an  interest  in  attending  future  Industry  Review 
Boards  as  well  as  requesting  to  be  on  the  distribution  list  for  program 
documentation.  Several  suppliers  expressed  an  interest  in  being  added  to  the 
list  of  supplier  demonstration  candidates. 

•  Mr.  Richard  Lopatka,  attended  a  National  Security  Industrial  Association 
(NSIA)  meeting  held  13-16  July  1986  as  an  invited  panelist  and  presented  a 
GMAP  overview.  The  objective  of  the  meeting  was  to  establish  a  foundation 
for  government  and  industry  cooperation  specifically  aimed  at  implementing 
CALS.  The  panel  topic  was  “Computer  Aided  Design /Computer  Aided 
Engineering  (CAD/CAE)  Design  Integration  for  Improved  Reliability  and 
Maintainability”. 
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•  Ms.  Diane  Koziol  Emmerson  from  Pratt  &  Whitney  presented  a  paper,  “Use 
of  Product  Models  in  a  CIM  Environment,"  to  the  CIMTECH  ’87  Conference 
in  Los  Angeles,  California  during  the  week  of  23  March  1987.  The  conference 
was  sponsored  by  the  Computer  &  Automated  Systems  Association  of  the 
Society  of  Mechanical  Engineers  (SME).  Approximately  100-150  people  from 
industry  and  academe  attended  this  segment  of  the  conference,  which  focused 
on  Supporting  Technology. 

This  paper  discussed  the  methods  used  to  design  product  data  information 
models  for  use  in  a  CIM  environment.  The  information  model  content, 
structiire,  and  capabilities  to  convey  product  shape  and  nonshape  information 
normally  communicated  by  the  engineering  drawing,  were  also  discussed.  In 
addition,  the  use  of  these  models  to  integrate  and  enhance  product  life  cycle 
activities  was  discussed. 

•  In  mid  1987,  Mr.  Richard  Lopatka  attended  a  ManTech  sponsored  industry 
review  of  FIMS.  This  industry  meeting,  held  to  review  a  study  contracted  to 
Cincinnati  Milacron,  examined  ways  to  better  develop  and  use  across  factory 
floor  applications  software  funded  by  the  Air  Force.  The  need  for  more  use  of 
standards  in  software  interfaces  was  highlighted.  Several  other  industry 
representatives  associated  with  the  GMAP  Industry  Review  Board  attended. 

•  Mr.  Don  Deptowicz  from  Pratt  &  Whitney  attended  the  REPTECH  ’88 
workshop  in  Salt  Lake  City,  Utah,  25-27  January  1988.  The  primary  purpose 
of  this  workshop  was  to  disseminate  information  concerning  new  repair 
technologies  and  related  CIM  activities  throughout  the  DoD  maintenance 
facilities.  During  the  CIM  Technology  exchange,  Mr.  Deptowicz  presented  a 
paper,  “Implementation  of  GMAP  Technologies  for  Logistics  Support 
Applications’’.  Although  the  primary  focus  of  the  workshop  was  on  automa¬ 
tion  applications  and  the  flexibility  that  they  provide  in  a  repair  environment, 
particular  emphasis  was  placed  on  the  flow  and  exchange  of  PDD. 

•  Mr.  Perlotto  also  attended  and  presented  at  the  Product  Data  Initiative  (PDI) 
form  features  Workshop  held  at  the  Martin  Marietta  Energy  Systems  in  Oak 
Ridge,  Tennessee,  22-24  June  1988.  This  workshop  was  sponsored  by,  and 
intended  to  benefit,  the  Department  of  Energy  (DoE)  sponsored  PDI  program 
operated  in  the  Nuclear  Weapons  Complex  (NWC).  Participating  companies 
and  government  organizations  included  all  the  national  laboratories  such  as 
Lawrence  Livermore,  Sandia,  and  Los  Alamos,  and  their  respective  manufac¬ 
turers  such  as  Allied-Signal-Kansas  City,  and  Martin  Marietta-Oak  Ridge. 

Invited  speakers  represented  PDES  management  and  government  projects 
such  as  GMAP,  Integrated  Design  Support  System  (IDS),  the  Navy  Rapid 
Acquisition  of  Manufactured  Parts  (RAMP),  the  NBS’  Advanced  Manufac¬ 
turing  Research  Facility  (AMRF),  PDES  Inc.,  and  Ckimputer  Aided  Manufac- 
turint'-Intemational  (CAM-1). 

The  PD]  is  developing  PDD  and  exchange  mechanism  for  use  within  the 
NWC  to  communicate  designs  from  the  national  laboratories  to  the  manufac¬ 
turers.  The  results  are  to  be  made  available  to  the  PDES  organization  after 
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they  are  tested  and  validated.  The  areas  in  development  include  geometry, 
form  features,  tolerances,  numerical  controls  (N/C),  inspection,  and  PSCM. 

These  areas  are  being  investigated  and  modeled  independently  from  the 
PDES  work. 

•  In  May  1988,  GMAP  personnel  attended  a  meeting  with  Mr.  P.  Motz  of 
Cincinnati-Milacron,  who  represented  the  Intelligent  Machining  Workstation 
(IMW),  to  review  the  current  requirements  of  the  IMW  contract  for  GMAP 
models.  The  model  of  interest  for  a  phase  1  demonstration  of  the  IMW  was 
reviewed  and  their  PDD  modeling  strategy  was  detailed.  Mr.  K.  Perlotto  then 
created  the  detailed  PDD  model  specification  for  the  IMW  part  for 
subsequent  review.  This  specification  contained  instances  of  all  the  entities 
required  to  create  the  model,  included  all  attribute  data  values,  and  could  be 
used  as  an  input  guide  to  the  modeler.  The  GMAP  PDD  working  form  model 
of  the  sample  test  bracket  was  then  created  for  the  IMW  program  and 
delivered  after  converting  it  to  a  GMAP  exchange  file  using  the  System 
Translator. 

•  On  26  May,  representatives  from  die  United  States  DoT  Transportation 
System  Center,  located  in  Cambridge,  Massachusetts,  visited  Pratt  & 

Whitney  to  learn  about  the  technical  accomplishments  in  GMAP.  This  office, 
formerly  part  of  NASA,  was  supporting  DoD  CALS  work. 

•  A  Pratt  &  Whitney  GMAP  representative  attended  the  Machining  Initiatives 
Aerospace  Subcontractors  (MIAS)  Industry  Review  Board  meeting  held  11-12 
May  1988  in  Cincinnati,  Ohio,  to  determine  if  the  Small  Manufactures 
Improvement  Services  (SMIS)  could  be  a  viable  avenue  for  GMAP  technology 
transfer  work.  Based  on  initial  findings  at  the  meeting,  it  appeared  that  SMIS 
might  be  a  viable  avenue  for  GMAP  technology  transfer. 

•  On  8  June  1988,  representatives  from  Grumman  Data  Systems,  a  division  of 
the  Grumman  corporation,  met  with  members  of  the  GMAP  technical  team 
for  purposes  of  technology  transfer.  Systems  analysts  from  Grumman 
working  on  the  Rapid  Acquisition  of  Manufactured  Parts  (RAMP)  program 
explained  the  requirement  to  drive  RAMP  with  digital  data  or  PDES,  if 
available.  They  were  interested  in  exploring  the  concepts  of  GMAP  and  how 
they  might  be  utilized  in  their  work. 

The  Grumman  representatives  were  very  interested  in  the  software  that 
would  be  available  to  them  at  the  end  of  the  GMAP.  They  expressed  interest 
in  using  the  GMAP  PDD  Elditor  to  build  PDD  models.  The  capabilities, 
flexibility,  and  limitations  of  the  PDD  Editor  were  discussed. 

•  On  31  October  1988,  Ms.  Diane  Emmerson  from  Pratt  &  Whitney,  presented 
a  GMAP  related  paper  entitled,  “Product  Definition  Data:  Implementation 
Issues,”  at  AUTOFACT’SS,  in  a  technical  session  devoted  to  PDD.  The  paper 
focused  on  iseiies  tlutt  surfaced  during  the  implementation  phase  of  GMAP 
and  the  insight  that  was  necessary  to  put  this  technology  into  production.  It 
presented  an  overview  of  the  GMAP  objectives  and  accomplishments.  It  also 
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described  PDD  and  bow  it  was  used  in  the  product  life  cycle.  The  paper  then 
described  how  the  GMAP/PDDI  system  software  components  were  used  to 
enable  active  file  exchange  in  a  heterogeneous  computer  environment,  and 
how  PDD  was  verified  in  GMAP. 

Other  presentations  in  the  session  included  a  PDES  update  by  Mr.  Brad 
Smith,  of  the  NIST,  and  the  use  of  PDES  in  the  NAVY  RAMP  program  and 
in  the  DOE.  The  session  was  chaired  by  Mr.  Anthony  Skomra  of  Automation 
Technology  Products  (ATP). 

•  GMAP  was  included  as  part  of  a  Pratt  &  Whitney  display  at  the  IMIP 
conference  held  in  Atlanta,  Georgia  in  December  1988.  This  display  provided 
an  ovei^-iew  of  the  GMAP  contract  work  and  focused  on  the  GMAP  interface 
to  the  RFC  system. 

•  GMAP  personnel  held  a  separate  debriefing  on  17  February  1989  that  focused 
on  how  the  Air  Force  Logistic  Centers  could  benefit  from  the  GMAP  results. 

."'he  GMAP  team  provided  insight  into  what  GMAP  concepts  could  be  applied 
at  *’he  ALC  today,  and  how  the  PDES  could  be  used  in  the  future. 

Prest  "'tations  were  also  made  by  Pratt  &  Whitney  and  McDonnell  Aircraft 
Compai.y  (MCAIR)  personnel  on  how  they  will  be  applying  GMAP  within 
their  respective  companies. 

The  debriefing  objective  was  to  report  on  the  GMAP  contract  and  to  gain 
logistics  centers’  support  for  the  use  of  digital  data.  It  was  noted  that  the 
logistics  centers  have  evolved  from  using  paper  to  using  film.  The  next  step  is 
the  evolution  to  using  digital  data.  The  message  of  this  debriefing  is,  "a  lot  of 
good  work  was  performed  tinder  the  GMAP  program.  Here  is  what  use  of 
digital  data  can  do  for  the  logistics  center  in  the  future.’ 

•  Plans  were  developed  for  an  end-of-contract  Industry  Debriefing.  The 
debriefing  was  scheduled  for  late  May  1989,  in  the  NIST  area  of  Gaithersburg, 
Maryland.  This  Debriefing  was  to  be  the  major  avenue  to  disseminate  the 
salient  results  of  the  GMAP  program  to  appropriate  representatives  of 
industry  and  Government.  However,  it  was  decided  to  consolidate  this 
Debriefing  with  CIM  Industry  Days  to  reach  a  broader  segment  of  interested 
parties. 

•  Plans  were  developed  for  participation  in  CIM  Industry  Days.  This  confer¬ 
ence  is  scheduled  for  24-27  July  1989  in  Williamsburg,  Virginia.  CIM  Industry 
days  is  hosted  by  the  Air  Force  and  will  bring  together  leaders  from 
Government,  industry,  and  academia  to  exchange  views  and  information  on 
various  issues  relating  to  manufacturing  technology.  The  theme  of  the 
conference  is  “Integrated  Manufacturing:  More  than  Just  Technology”. 

Our  presentations  will  include  an  overview  and  key  findings  of  GMAP  as  well 
as  a  display  booth.  We  will  staff  the  booth  with  Pratt  &  Whitney  personnel 
who  were  actively  involved  in  GMAP.  We  also  will  make  use  of  GMAP 
videotapes  within  the  exhibit.  Literature  will  be  available  describing  the 
GMAP  program,  program  deliverables,  and  lessons  learned. 
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•  In  response  to  a  request  from  the  National  Computer  Graphics  Association 
(NCGA),  Ms.  Linda  Phillips  and  Ms.  Diane  K.  Emmerson  prepared  a  paper 
entitled,  “GMAP:  A  Prototype  in  Active  File  Exchange,”  for  presentation  at 
the  NCGA  ’89  conference  and  exposition.  The  conference,  sponsored  by 
NCGA,  will  be  held  at  the  Philadelphia  Civic  Center  17-20  April  1989.  The 
paper  discusses  different  architectures  for  file  exchange,  as  well  as  the  GMAP 
software  architecture.  It  further  explains  how  the  GMAP  software  enables 
active  file  exchange  and  discusses  the  advantages  and  lessons  learned  using 
this  architecture.  The  paper  has  been  approved  for  public  dissemination  by 
the  Air  Force. 
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APPPENOIX  C 

TECHNICAL  ISSUES  IN  PRODUCT  DATA  TRANSFER 

Several  technical  issues  in  implementing  electronic  product  data  exchange  in  both  military 
and  commercial  applications  exist  today.  These  issues  need  to  be  addressed  in  a  cooperative 
industry  setting  involving  the  system  suppliers,  the  users,  as  well  as  customers  of  users.  These 
issues,  summarized  on  the  attached  graphic,  are  in  four  areas: 

1.  there  is  a  fundamental  technology  shortfall  which  requires  research  and 
development; 

2.  product  data  exchange  capahiiities  are  in  a  highly  dynamic  and  evolving 
environment  which  makes  implementation  and  standards  extremely  difficult 
to  manage; 

3.  product  data  exchange  needs  to  be  addressed  in  light  of  the  entire  life  cycle, 
intorducing  integration  challenges; 

4.  special  DoD  requirements  compound  the  general  industry  requiremnents. 

T  .>chnology  Shortfalls 

•  Lack  of  full  product  description  databases  —  The  database  structures  to 
represent  and  manage  product  data  have  not  been  totally  defmed.  The 
database  software  to  manage  these  structures  are  still  in  prototype  mode. 

Product  Definition  Data  Interface  (PDDI)/GMAP  is  representative  of  this 
capability.  The  electronic  versions  of  engineering  drawings  do  not  include  all 
the  data  necessary  for  all  the  applications  throughout  product  life  cycle 
operations  to  be  able  to  automatically  use  that  original  drawing. 

•  Lack  of  a  full  product  modeler  —  The  solids  modelers  that  exist  today  do  not 
allow  a  user  to  enter  everything  necessary  to  generate  full  product  description 
databases.  Today’s  modelers  are  good  at  creating  geometry  and  topology,  but 
fail  to  provide  computer  sensible  information  such  as  tolerancing,  features, 
and  notes.  Input  to  the  database  is  currently  a  significant  technology  barrier. 

•  Shortfalls  in  applications  ready  to  use  PDD  —  Since  there  is  a  lack  of  full 
product  description  databases,  there  are  very  few  existing  applications 
capable  of  using  such  a  database. 

•  Lack  of  configuration  control  capability  —  There  is  a  need  for  better 
traceability  of  product  design  releases.  Current  product  designs,  as  well  as 
designs  of  mature  products,  and  their  revisions  must  be  retrievable  and 
accurately  associated  among  operations  within  an  enterprise.  There  is  a  great 
deal  of  manual  verification  currently  taking  place. 

•  Lack  of  PDD  communications  network  —  Today’s  communication  networks 
are  not  designed  to  handle  the  massive  amount  of  data  present  in  a 
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sophisticated  computer  file  containing  full  product  descriptions.  Limited  or 
condensed  product  descriptions  are  currently  transmitted.  Magnetic  ta{>e 
systems  are  not  effective  for  rapid  and  fiequent  exchanges. 

•  System  performance/workstation  functionality  —  More  advances  are  needed 
in  workstation  speed  and  power,  and  compression  techniques  to  store  large 
amounts  of  data. 

•  Proprietary  database  security  —  In  many  cases,  prime  contractors  are 
allowing  subcontractors  direct  access  to  product  descriptions  and  internally- 
developed  application  software.  The  activity  could  be  increased  if  effective 
methods  were  developed  to  control  who  is  allowed  to  access  data  systems  and 
who  is  allowed  to  manipulate  accessed  data  or  software. 

In  addition,  product  data  exchange  capabilities  are  in  a  highly  dynamic  and  evolving 
environment  which  makes  implementation  and  standards  extremely  difficult  to  manage.  The 
issues  that  illustrate  this  problem  are: 

•  Numerous  levels  of  implementation  —  The  current  standards,  such  as  IGES, 
are  not  implemented  to  the  same  extent  by  CAD/CAM  system  developers. 

Data  conversion  from  one  system  to  another  can  thus  become  very  time 
consxuning  and  error  prone.  Also,  companies  differ  in  the  degree  to  which  they 
commit  to  this  technology. 

•  Technology  in  rapid  state  of  change  —  Today,  state-of-the-art  systems  can 
become  obsolete  quickly.  For  this  reason,  some  companies  wait  for  the  system 
that  is  the  ‘best*  system  for  them.  Others  are  continually  experimenting  with 
new  capabilities. 

•  Overlapping  technologies  —  Currently,  companies  are  installing  systems  such 
as  optical  disk  systems  to  automate  the  storage,  retrieval,  and  archiving  of 
drawings.  These  systems  require  communication  networks,  specialized  termi¬ 
nals,  computers,  and  so  on.  In  parallel  to  this,  companies  are  also  attempting 
to  integrate  their  CAD/CAM  systems  for  the  use  and  manipulation  of 
intelligent  drawings.  Again,  these  systems  require  communication  networks, 
specialized  terminals,  computers,  cmd  so  on.  In  most  cases,  only  a  small 
percentage  of  the  hardware/softwaie  environment  is  common  to  both 
implementations.  This  creates  problems  in  financial  justification,  training, 
establishing  operational  procedures,  and  so  on. 

•  Dual  manual/computerized  environment  —  Manual  systems  do  not  change  to 
a  totally  computerized  system  overnight.  Companies  have  to  keep  both 
systems  going  while  they  are  transitioning  and  pay  an  operational  cost 
penalty  in  the  transition. 

•  Standards  for  a  rapidly  evolving  technology  —  The  IGES/PDES  efforts  are 
attem|»ting  to  standardize  a  technology  that  is  not  yet  developed.  The  PDES 
effort  is  more  of  a  R&D  activity  than  a  standardization  effort. 
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•  Education/training  gap  —  Employees  throughout  an  enterprise  must  be 
trained  not  only  how  to  use  product  data  generation,  manipulation,  and 
transfer  equipment  but  also  how  to  use  it  efficiently  and  effectively. 
Employees  must  leam  that  failure  to  look  at  the  overall  control  requirements 
of  the  system  may  result  in  problems  later  in  the  product  life  cycle.  Employees 
in  the  life  cycle  range  from  those  with  great  expertise  in  ming  computers  to 
those  with  no  computer  based  knowledge. 

Integrated  Approach 

Other  issues  deal  with  the  need  of  product  data  exchange  to  be  addressed  in  light  of  the 
entire  life  cycle,  introducing  integration  challenges. 

•  Heterogeneous  computing  environment  —  Users  are  not  all  going  to  acquire 
one  single  system.  Hiere  is  not  one  single  solution  to  all  product  data  transfer 
problems.  Different  computer  systems  will  prevail  among  companies  and  the 
challenge  becomes  one  of  integrating  these  systems,  hopefully,  to  the  degree 
that  it  becomes  transparent  to  the  user. 

•  Nonstandard  representations  of  data  —  There  are  various  ways  of  creating  a 
specific  geometric  feature,  such  as  a  spline,  among  system  developers.  As  a 
result,  product  data  transfers  is  sometimes  impossible,  other  times  the 
accuracy  is  uncertain. 

•  Turnkey  systems  not  adaptable  —  Many  available  systems  do  not  meet  the 
specific  needs  of  many  companies  with  unique  product  lines.  Also,  they  are 
not  easily  adaptable  to  meet  the  company’s  unique  needs  or  the  company  is 
not  large  enough  to  employee  the  resources  necessary  to  modify  such  a 
system.  On  the  other  hand,  many  companies  that  acquire  such  systems  and 
modify  them  to  fit  their  unique  needs  discover  that  their  system  is  no  longer 
compatible  with  others  of  the  same  manufacture. 

•  Full  life  cycle  coverage  —  Single  product  databases  that  can  be  used  by  the 
many  islands  of  automation  in  the  life  cycle  of  a  product  do  not  exist. 
Numerous  translators  are  required  to  provide  product  data  transfer  effectively 
among  the  many  life  cycle  operations.  Translations  are  considered  deficient 
for  many  applications. 

•  Interface  to  application  software  —  Existing  application  software  can 
generally  use  the  databases  that  are  now  available.  However,  as  we  move 
toward  the  use  of  full  product  description  databases,  we  will  be  required  to 
develop  new  interfaces  to  these  existing  applications.  But,  we  will  also  have 
the  opportunity  to  automate  life  cycle  applications  that  previously  needed  a 
more  complete  database. 

•  Feedback  to  design  —  Existing  iterative  design  cycles  do  not  always  provide 
the  designer  mth  the  information  req\iired  for  accurate  decision-making  early 
in  the  design  process.  Advances  in  product  data  transfer  technology  will 
provide  more  opportunities  for  effective  feedback  of  information  to  the  design 
process. 
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